7 Widgets to Embed on Your Lovable Site

Lovable is very good at the part that used to take the longest. You describe a site, it writes one, and within an hour you are looking at something with real layout, real components and a real deployment.

Then you try to take a booking. Or collect an email address that actually arrives somewhere. Or show a cookie banner because someone in the EU is about to load the page. And you notice that the generated app is a beautiful front end with nothing behind it, and that every one of these small features is a project of its own.

This is where embedded widgets earn their place. Not as decoration, but as the parts of a website that are solved problems and are not worth rebuilding: a form with delivery and spam filtering behind it, a calendar that knows about timezones, a consent banner that stores a choice. You paste one line, the feature exists, and you go back to the thing you were actually building.

Below are seven that fit a Lovable project particularly well, chosen because each one covers a job the generated app does not do on its own. Before them, there is one technical detail that catches nearly everybody, and it is worth two minutes.

Why a Pasted Embed Code Sometimes Does Nothing

Most embed instructions on the internet, including some of ours, were written for classic site builders. They say something like "paste this into the HTML field" or "add it to a code block". Lovable does not have an HTML field or a code block, because it is not that kind of tool. It generates a React application.

That matters for one specific reason. A typical embed snippet is two pieces: a container element, and a script tag that loads the widget into it. Ours looks like this:

<div class="commonninja_component pid-YOUR-WIDGET-ID"></div> <script src="https://cdn.commoninja.com/sdk/latest/commonninja.js" defer></script>

If you hand that whole thing to React as a string of HTML, the container appears and the script tag does not run. This is not a bug in Lovable and not a bug in the widget. It is how browsers work: a script element inserted into a page as parsed HTML, rather than created as a real script element, is deliberately not executed.

The visible symptom is the confusing part. There is no error. There is no broken image. There is simply a gap on the page where the widget should be, which looks exactly like the widget failing to load, so people go and change the widget settings, which of course does nothing.

Three Ways to Add an Embed That Actually Work

All three are fine. Pick by how much you want to touch the code.

Ask Lovable to do it. This is the shortest path and it works on any plan, because Lovable is the one writing the change. Paste the snippet into the chat and say what you want, in roughly these words: "Add this embed to the contact section of the home page. It is a third party widget, so make sure the loader script is added properly and actually executes, not injected as raw HTML." That last sentence is doing real work. Without it you will sometimes get the raw HTML version and the silent gap described above.

Put the loader script in the app shell. A Lovable project has an index.html at its root, which is the page the whole app is mounted into. A script tag there is a normal script tag in a normal HTML document, so it runs the way you expect, once, for every page of the app. Then all a component needs is the container div. This is the cleanest arrangement when you are going to use more than one widget, because the loader is fetched a single time instead of per component. Editing files by hand needs a paid Lovable plan, since Lovable's code editor is read only on the Free plan.

Let a component load it. If you would rather keep everything inside one component, the pattern is to render just the container, then create the script element in code after the component appears on screen and append it to the document. Lovable will write this correctly if you ask for it in those terms. It is the right choice when the widget lives on one page only and you do not want its script loading on every other page.

One habit that saves time regardless of route: after adding an embed, open the browser console and the network tab and confirm the widget script was actually requested. If it was not, the problem is the loading method and nothing else. If it was, and the container is still empty, check that the widget identifier in the container class matches the one in your embed code.

1. A Contact Form That Delivers Somewhere

This is the one people underestimate, and it is usually the first thing that goes wrong on a generated site.

Lovable will happily build you a beautiful contact form. Fields, labels, validation, a submit button with a nice hover state, the lot. What it will not do by default is deliver the message. A form needs somewhere to send data, which means an endpoint, which means a backend, storage, an email service, and a spam defence, and now your afternoon has a shape you did not plan.

An embedded form arrives with all of that already attached. Submissions land in an inbox and in a dashboard, the spam filtering is somebody else's problem, and the fields are configured in a visual editor rather than in code. If your site is a portfolio, a landing page, a small business site or a launch page, that is the entire feature, done.

Two things worth setting up on day one. Turn on the email notification and send a real test message to yourself before you tell anyone the site is live, because a form that quietly fails looks identical to a form nobody is using. And keep the field count honest: every field you add is a reason to abandon, and name plus email plus message answers almost every enquiry a small site receives.

Start from the contact form widget, or read the platform specific notes on the contact form for Lovable page.

2. An AI Chatbot for the Questions You Keep Answering

Of everything people search for alongside Lovable, chat and bots come up the most. That is not a coincidence: an AI built site attracts an audience that expects an AI shaped way of asking questions.

The useful version of this is narrower than it sounds. A chatbot on a small site is not there to be impressive. It is there to answer the same five questions you are tired of answering: what does it cost, do you work with people in my country, how long does it take, how do I get started, can I talk to a person. A bot that answers those five well and hands over cleanly when it cannot is worth far more than one that improvises confidently about things it does not know.

Which means the setup work is not technical, it is editorial. Write down the questions you actually receive, give the bot the real answers, and give it an honest exit: a line that says it does not know and a link to a form or an email address. Then read the transcripts for a fortnight. They are the cheapest customer research you will ever get, and they usually reveal that the site is missing a paragraph somewhere.

The AI chatbot widget covers this, and there is a Lovable specific walkthrough on the AI chatbot for Lovable page. If you want the wider comparison first, we have a piece on how to add an AI chatbot to your website that weighs up four different approaches.

3. A Booking Calendar, Because Timezones Are a Trap

Booking looks like a small feature and is not. A working appointment system needs availability rules, buffer times between slots, a limit on how far ahead people can book, cancellation and rescheduling, confirmation emails, reminder emails, and timezone handling that survives a daylight saving change in one country but not the other.

You can ask Lovable to build all of that. You will get something that demos well, and then you will spend the following month on the edge cases, most of which arrive as an email from a confused customer who turned up an hour early.

An embedded booking widget hands you the finished version of that list. The part worth your attention is the configuration rather than the installation: set a realistic buffer so back to back bookings do not become a problem, cap the booking window so your calendar six months out is not already committed, and make the confirmation email say something useful about what happens next. Then book a slot yourself, from a different timezone if you can manage it, and read every email the system sends.

The booking widget is the starting point, with platform notes on the booking widget for Lovable page. For the wider question of what a booking system is actually doing for a business, there is the role of booking widgets in modern business operations.

4. A Cookie Consent Bar, Because Somebody Will Ask

This is the least exciting item on the list and the one most likely to matter. The moment a site has analytics, an embedded video, a chat widget or an advertising pixel, it is setting cookies on behalf of a third party, and in several jurisdictions that requires consent before it happens rather than a notice afterwards.

A generated site does not ship with a consent banner, and by the time you think about it there are usually three or four scripts already running. A consent widget gives you the banner, the accept and reject options, the record of what a visitor chose, and the ability to keep that choice across visits.

Two honest caveats. A banner is a component of compliance, not the whole of it: what you also need is to know which scripts on your site set cookies and what each one does, and no widget can work that out for you. And a reject option that is harder to find than the accept option is the single most commonly criticised pattern in this area, so give both the same weight. Where the rules that apply to you are genuinely unclear, that is a question for someone qualified rather than for a settings panel.

See the cookie consent bar widget and the cookie bar for Lovable page.

5. A Website Translator for the Audience You Did Not Plan For

Something interesting shows up in what people search for around Lovable: translating a Lovable site is one of the most common requests, and it is asked in a notably practical way. People are not researching internationalisation strategy. They have a finished site and an audience that does not read the language it is written in.

Doing this properly in a React application means an internationalisation library, a translation file per language, every string extracted from every component, and a system for keeping those files in sync as the site changes. It is the correct approach for a product with a real international market and it is a large amount of work for a site with one page and one visitor from Brazil.

A translator widget is the pragmatic middle. It adds a language selector, translates the page in place, and asks nothing of your codebase. The quality is machine quality, which is fine for navigation, headings and body text, and not fine for legal terms, pricing details or anything where a mistranslation costs you something. A reasonable rule: let the widget handle the pages that help someone understand what you do, and hand write anything that commits you to something.

The website translator widget covers it, with a Lovable specific page at website translator for Lovable, and a general walkthrough in how to add a website translator to your website.

6. An Instagram Feed to Prove the Lights Are On

A new site has a credibility problem that has nothing to do with how it looks. It looks new. There is no history on it, nothing that says a real person has been running this for a while, and a visitor deciding whether to trust you notices that even if they could not tell you why.

A live social feed fixes that cheaply, because it is the one section of the page that updates without you touching the site. It shows recent activity, real photographs, and dates that are not from last year. On a portfolio, a restaurant, a studio or a shop, it often does more persuading than the copy above it.

Three practical notes. Put it low on the page, because it is supporting evidence and not your pitch. Choose a grid size that still looks deliberate on a phone, which usually means fewer posts than you would pick on a desktop. And be honest with yourself about posting frequency: a feed whose newest post is eight months old is worse than no feed at all, because it advertises the exact thing you were trying to disprove.

The Instagram feed widget handles this, with platform notes on Instagram feed for Lovable, and a general comparison in how to embed an Instagram feed on your website.

7. A WhatsApp Button for the Conversation People Actually Want

The last one is the smallest and has the best return for the effort involved. A floating button that opens a WhatsApp conversation, pre-filled with a first message, on a phone, in the app the person is already logged into.

Why it works: a contact form is a message sent into silence, where the sender has no idea whether it arrived or when a reply might come. A chat thread is a conversation with a visible history, and the reply lands somewhere they will actually see it. In large parts of Europe, Latin America, Africa, the Middle East and South Asia this is simply how people expect to contact a business, and a site that offers only a form is asking for a formality that many visitors will not bother with.

The trade you are making is a real one, so make it deliberately. This routes business enquiries to a phone, which means notifications outside working hours and no shared inbox unless you set up a business account properly. If that does not suit how you work, do not add it. If it does, set a sensible pre-filled message that tells you which page they came from, so you are not opening every conversation with "how can I help".

See the WhatsApp button widget and the WhatsApp button for Lovable page.

How to Choose Which of These You Actually Need

Seven is a menu, not a shopping list. Adding all of them to a one page site would be worse than adding none, because each widget is a piece of the page competing for attention and a piece of JavaScript competing for load time.

A test that works well: for each widget, name the specific thing that goes wrong if it is not there. If you can answer in one sentence, add it. If you find yourself constructing a scenario, skip it.

• Contact form. Enquiries have nowhere to land. Add it, almost always.
• Cookie bar. You have analytics or embeds and visitors in a jurisdiction that requires consent. Add it, and understand what your scripts do.
• Booking. Your business runs on appointments and you are currently arranging them by email. Add it.
• Chatbot. You answer the same handful of questions repeatedly. Add it once you have written the real answers down.
• Translator. You can name an audience that does not read your language. Add it for the explanatory pages only.
• Instagram feed. You post regularly and the work is visual. Add it, low on the page.
• WhatsApp button. Your customers already message businesses this way and you are willing to answer. Add it.

The ordering that tends to work in practice is contact form first, then whichever single widget matches how your customers actually reach you, then compliance, then everything else once the site has visitors whose behaviour you can look at rather than guess about.

Keeping the Page Fast Once You Have Added a Few

Every embed costs something. The honest version of that sentence is that a widget adds at least one network request, some JavaScript that parses and runs after your own page is already interactive, and often a font or a stylesheet of its own. One or two of these is invisible. Six from six different providers is a slow page, and on a phone on a mediocre connection it is a noticeably slow one.

Four habits keep it manageable:

• Prefer one provider over several. Widgets from the same platform share a single loader script, so the second and third widget cost far less than the first. Five widgets from five companies means five separate loaders with nothing shared between them.
• Lazy load anything below the fold. A social feed or a review wall at the bottom of the page has no business loading before the visitor has scrolled anywhere near it.
• Give containers a fixed height. A widget that appears late and pushes the content below it down the page is the layout shift that Google measures and that visitors experience as the page moving under their thumb. Reserving the space in advance removes it entirely.
• Measure on a phone, not on your laptop. Your development machine on office wifi is the least representative device your site will ever be viewed on.

We go through this in more depth in how to improve website loading speed with widgets, which applies to any stack and not only to Lovable.

The Short Version

A Lovable project gets you a real site in an afternoon and stops precisely where the plumbing begins. The seven widgets above are that plumbing: a form that delivers, a bot that answers, a calendar that books, a banner that asks permission, a translator, a feed and a button that opens a conversation.

The one thing to remember when you add any of them is the React detail from the top of this article. If an embed leaves an empty gap on your page, do not go looking in the widget settings. The script almost certainly never ran, and the fix is to put the loader in index.html or to ask Lovable to add it as a script element rather than as raw HTML.

If you want to see the full set, the widget catalogue lists everything, and there is a Lovable platform page with the per widget install notes. And if you are still choosing a builder rather than filling one in, our comparison of the best AI website builders for customization is a reasonable place to start.