Feedback Bubble
Guides

Published 4 August 2026 · By Jonathan Jones

How to Add a Feedback Widget to Next.js

A practical guide for indie developers on adding a feedback widget to a Next.js app, capturing real user feedback without leaving the page.

Adding a feedback widget to a Next.js app takes about five minutes. You paste a small script into your root layout file and visitors can send bug reports, feature ideas, or questions without leaving the page. This guide walks through exactly how to do that and covers a few things worth knowing before you start.

Why bother with a feedback widget at all

Most indie SaaS founders run their product on a mix of support emails, the occasional DM, and gut instinct. That works at the very start, but it leaves gaps. You rarely know which page a user was on when they hit a problem, what device they were using, or how many people gave up quietly without ever reaching out.

A feedback widget lowers the barrier enough that more visitors actually say something. Because it sits on the page itself, you also get useful context automatically: the page path, browser, device type, and viewport size come through with each submission. That reduces the back-and-forth you would otherwise need to reproduce a bug.

For a solo developer or a small team, a lightweight widget is often a better fit than a full survey platform or help-desk system. You just need a simple way to hear from users and enough context to act on what they say.

What makes Next.js slightly different

Next.js handles script loading differently from a plain HTML site. You should not drop a raw script tag directly into a JSX component without thinking about how it will be evaluated. The framework provides a built-in Script component from next/script that manages loading strategy for you, and the right place to add a sitewide widget is the root layout file rather than an individual page.

If you paste a widget script into a page-level component, it will only load on that page and may re-initialise on every navigation. Putting it in app/layout.tsx (the App Router default since Next.js 13) means it loads once and persists across the whole app.

Step-by-step: adding a feedback widget to Next.js

The steps below use Feedback Bubble as the example. It is a lightweight widget built for indie founders and small SaaS teams, and it has a dedicated Next.js installation path. The same general approach applies to other script-based widgets.

1. Create your widget and get your site key

After creating an account, go to Dashboard > Bubbles > New bubble. Give it an internal name and enter the full origin of your Next.js site, for example https://www.example.com. This origin is a security restriction. Feedback Bubble checks that requests come from the approved domain before returning the widget or accepting submissions.

Once you save the bubble, you will have a public site key. That key identifies your widget configuration but is not a secret; the server still validates the origin, bubble status, and account access on every request.

2. Open the installation instructions

Go to Dashboard > Bubbles and select Install on your bubble. The installation window has separate tabs for HTML, React, Next.js, and WordPress. Select the Next.js tab. The generated code already contains your site key so you can copy and paste it directly.

3. Update app/layout.tsx

Open the root app/layout.tsx file in your project. Add the following import at the top if it is not already there:

import Script from 'next/script'

Then place the generated Script component inside your <body> element, after your page content. A minimal layout looks like this:

export default function RootLayout({ children }) {

return (

<html lang="en">

<body>

{children}

<Script src="https://cdn.getfeedbackbubble.com/widget.js"

data-site-key="YOUR_SITE_KEY"

strategy="afterInteractive" />

</body>

</html>

)

}

Use the exact script tag from the installation window rather than typing this manually. The generated code contains your real site key and the correct source URL.

4. Deploy and confirm

Deploy your changes and load your site. The floating launcher should appear in the bottom corner you selected during setup. Open it, submit a test message, and check Dashboard > Inbox > Needs review to confirm the submission came through with the correct page path and device context.

Customising the widget without reinstalling

One thing worth knowing: after you update the widget's appearance, wording, accent colour, or feedback types in the bubble editor, you do not need to change the script in your layout file. The widget loads its configuration through the site key on each page load, so saved changes take effect without redeployment.

You would only need to update the script if you replace the widget entirely or change the site key, which would happen if you deleted the bubble and created a new one.

What visitors see and what you receive

Once the widget is live, visitors see a small floating launcher in the corner of every page. When they open it, they can select a category and write a message. Depending on how you have configured the bubble, the available categories are Issue, Idea, and Question. You can enable or disable each one independently from the bubble editor.

If you have turned on reply requests, visitors can optionally provide an email address. They are not required to do so for a standard submission, which tends to increase the number of people who actually send feedback.

Each submission in your inbox includes the page title, path, and full URL, along with browser name, operating system, device type, viewport size, and a few other details. That context does not replace a clear message from the user, but it does mean you rarely need to ask follow-up questions just to reproduce a reported issue.

Organising feedback once it arrives

New submissions land in Needs review. From there you can filter by feedback type, search by keyword, or filter by a specific bubble if you have more than one site on your account. You can move messages to Saved if you want to keep them for reference, or to Archive when they no longer need attention.

When several related messages point to the same underlying problem or request, you can group them under a planned change rather than treating each one separately. This keeps the original customer wording intact while letting you give the actual work an outcome-focused name, for example "Improve error messages on the billing page" rather than copying a single user's phrasing.

A few things to get right from the start

  • Set your allowed website to the exact origin including the protocol, for example https://www.example.com rather than just example.com. A mismatch will cause the widget to be rejected.

  • Put the Script component in the root layout, not in a single page component. This ensures the widget loads consistently across your app.

  • Test on a staging URL if your production domain is different. You may want a separate bubble for staging so feedback does not mix with production submissions.

  • Use the strategy="afterInteractive" attribute so the script loads after the page is interactive rather than blocking rendering.

  • Submit a real test message and check the inbox before telling users the widget is live. It takes thirty seconds and confirms the installation is working end to end.

Common mistakes when adding scripts to Next.js

A few patterns cause problems specifically with Next.js.

Using a raw <script> tag in JSX is the most common one. Next.js will warn about this and it may not behave as expected, particularly with hydration. Use the Script component from next/script instead.

Adding the script inside a useEffect hook to dynamically inject it is another approach developers try. It works, but it is unnecessary here and adds complexity. The Script component already handles deferred loading cleanly.

Placing the script in a layout that only wraps part of your app is easy to miss if you have nested layouts. Check that the layout file you edit applies to every route where you want the widget to appear.

Keeping feedback connected to product decisions

Getting feedback is only useful if you do something with it. A widget makes it easier to collect, but the second step is deciding which messages are worth acting on and how.

Not every request should become a feature. A handful of users asking for the same thing is a signal, not a commitment. Group related submissions under a planned change, give that change a clear outcome name, and track it through Planned, Building, and Shipped stages in the Releases section. When the work ships, you can follow up with users who left an email address and asked for a reply.

Feedback from a widget is one source of evidence. It works well alongside user interviews and any analytics you already run. The goal is to reduce the number of decisions made purely on assumption, not to replace every other method.

Conclusion

Adding a feedback widget to Next.js comes down to importing the Script component, pasting the generated code into your root layout, and deploying. Once it is live, you have a low-friction way for real users to tell you what is broken, what they want, and what confuses them, without them ever leaving your site.

If you want to try it, the installation instructions with the exact Next.js code are available at Dashboard > Bubbles > Install once you set up a bubble. You can also read more about how the widget works on the features page.

Frequently asked questions

Does the widget work with the Next.js App Router and Pages Router?

The App Router approach uses app/layout.tsx. For the Pages Router, the equivalent location is pages/_app.tsx or a custom pages/_document.tsx. The principle is the same: add the script once at the root level so it loads across every page.

Will updating the widget design require a redeployment?

No. Changes to colours, wording, position, icon, and feedback types are loaded through the site key when the widget initialises. You only need to redeploy if you change the script itself, which would be unusual after the initial setup.

Can I use the same Feedback Bubble account for multiple Next.js projects?

Yes. One account supports up to five feedback bubbles, each with its own allowed website, design, and site key. All feedback from every site is managed in the same inbox, and you can filter by bubble to view submissions from a specific project.

What happens if a visitor submits feedback from an unapproved domain?

Feedback Bubble checks the origin of every request against the allowed website you set during bubble creation. Requests from an unapproved origin are rejected. This is why it is worth setting the allowed website to your exact production URL, and creating a separate bubble for any staging environment you want to test with.

Do I need to ask visitors for their email address?

No. The email address field is optional and only appears if you have enabled reply requests in the bubble editor. Visitors can submit an Issue, Idea, or Question without providing any contact details at all.