What to do when Astrina review widget is not showing on your website

Your page can load normally and still leave the Astrina review widget invisible. That is the first trap. The site works, the URL opens, the header and footer look fine, and the widget is just not there.

That difference matters because “the page is live” does not mean the widget rendered. A homepage can serve in 1 second, a product page can show its content, and the review widget can still fail on that one template. If you are checking every site you look after, this is the kind of issue that hides in plain sight.

Why is the Astrina review widget not showing even though the page is live?

Start with the narrow question: did the page load, or did the widget fail to appear? Those are not the same thing. A live page can return a 200 status, show text, and still have no review widget because the widget script never ran, the block was hidden, or the placement rule did not match.

One practical check helps here. Open the page in a normal browser window, not just inside the editor preview. Then refresh once. If the widget appears in preview but not on the published page, the problem is usually not the widget itself but the page setup, the template, or a condition that only applies after publish.

The “site works” part can distract people. It should not. If the widget is absent on a live page, treat that as a render issue first and a content issue second. That order saves time.

Is the widget actually enabled for this page or placement?

Many widget problems come down to a simple mismatch: the widget is enabled globally, but not for the page you are testing. A site owner may turn it on for the homepage, then expect it to show on every product page. That does not always happen automatically.

Check the widget settings for three things: page, template, and section. If Astrina lets you place the widget on specific areas only, make sure the placement rule includes the current page type. A blog post, a category page, and a landing page can each behave differently. One click in the wrong place is enough.

If you manage multiple pages, compare the working page with the missing one. Use the same template name, the same section, and the same widget rule. If one page shows reviews and another does not, the difference is usually in placement, not in the review content itself. For teams managing more than one property, every client site in one dashboard can make that comparison much faster.

Do not skip the small stuff. A widget can be enabled for “all product pages” and still miss one page because that page uses a custom template. That happens more often than people expect.

Is the widget code present on the page source?

If the widget is enabled, the next question is simple: is the code on the page at all? Open the page source or use the browser inspector and look for the Astrina embed snippet. If the snippet is missing, the widget cannot render. No script, no widget.

This check matters most after edits to a CMS template, page builder, or shared component. A developer may move the widget into a footer include, then later replace that include. Or an editor may swap a block and remove the embed without noticing. In both cases, the page still loads, which makes the missing widget feel mysterious when it is really just absent from the source.

Check the template, not only the page editor. If the widget was inserted once into a shared section, changing that section affects every page built from it. That is a single edit with a wide effect. If you use astrina through a custom integration, confirm the script still ships with the page output after the latest deployment.

One quick test helps here. Search the source for “Astrina” or the widget script URL. If nothing appears, the code is not being delivered to the browser. If the code appears, the issue has moved from “missing code” to “visible or blocked code.”

Could another element be covering or pushing the widget out of view?

Sometimes the Astrina review widget is on the page, but users cannot see it. That happens when another element overlaps it, a container collapses, or CSS pushes it below the fold in a way nobody expected. The page looks fine to you because you know where the widget should be. A visitor does not.

Accordion sections are a common culprit. Tabs are another. If the widget sits inside a collapsed tab or a panel that opens only after a click, it may technically render but remain hidden on first load. The same thing can happen with lazy-loaded sections, sticky banners, or consent bars that cover the bottom of the viewport.

Check the layout with the browser inspector. Look at the widget’s parent containers and see whether any of them have `display:none`, zero height, or overflow rules that clip content. Also check z-index values. A cookie banner with a higher z-index can sit on top of the widget and make it look absent.

One small detail can ruin the display. A wrapper div with a fixed height of 0 is enough. So is a theme rule that hides any element below a certain breakpoint. If the widget appears on desktop but not on mobile, the CSS is the first place to look.

Does the widget depend on consent, region, or a condition that blocks display?

Some widgets do not appear on first load because they wait for consent or a rule tied to region or device. That is normal if your setup uses consent gating. It becomes confusing only when the page owner expects the widget to appear before the visitor clicks “accept.”

Check whether the widget is configured to load after cookie consent. If it is, test the page twice: once before accepting, and once after. If the widget appears only after consent, the widget is working as designed. If it never appears, the consent rule may be too strict or the consent event may not be reaching the script.

Region-based rules can also hide the widget. A site may show the widget only in one country, one language, or one market. That is a normal business rule. It can also create the false impression that the widget is broken when a tester happens to be outside the allowed region.

Ask one concrete question: under which condition should the widget appear? Write it down. “After consent,” “on English pages,” or “only on product detail pages” is far more useful than “it should show everywhere.” Specific rules make debugging faster.

Is the widget blocked by browser extensions, ad blockers, or network restrictions?

Browser-side blockers are a frequent cause. Ad blockers, privacy extensions, corporate filters, and even some DNS-level tools can stop the widget script from loading. If the widget appears on your phone but not on a work laptop, the device may be the issue, not the site.

Test in a clean browser profile. Then test in incognito mode with extensions disabled. If the widget appears there, the problem is likely a blocker rather than a broken integration. That is useful information. It changes the next step from “fix code” to “identify which blocker is interfering.”

Network restrictions can also matter. A company firewall may block a third-party script domain. A strict browser setting may do the same. If the script request never leaves the browser, the widget cannot render. No amount of page refreshes will change that.

One practical split helps. If the widget fails for only one user, suspect extensions or network rules. If it fails for everyone, suspect the page, the template, or the script source.

What should you check in the browser console if the widget still does not appear?

If the widget is still missing, open the browser console and look for errors. The console often tells you whether the problem is a missing script, a blocked request, or a JavaScript conflict on the page. That one pane can save a long round of guesswork.

Start with the Network tab, then refresh the page once. Look for the Astrina script request. If it returns 404, the source is wrong. If it never appears, the embed may not be running. If it loads but then the console shows a JavaScript error, the widget may be breaking because another script on the page fails first.

Conflicts often come from other front-end code. A theme script can fail, then prevent later scripts from initializing. A page builder can inject duplicate code. A custom cookie tool can throw an error and stop execution. The widget may be innocent.

This is where one exact detail matters: the first error in the console. Not the last one. The first error usually points to the real break. If you are unsure, copy the page URL, the error text, and the time of the test. Those three items help a developer diagnose the issue much faster.

If you are also tracking other site features, keep the same habit on astrina articles and docs pages. A screenshot with the console open beats a vague note every time.

When should you escalate the issue to Astrina support or your developer?

Escalate when the basic checks are done and the widget still does not appear on the correct page, in the correct browser, under the correct condition. That usually means the problem is no longer a content setting. It is either an integration issue or a front-end conflict.

Before you send the ticket, collect five items: the page URL, the expected placement, what you already tested, any console errors, and whether the widget appears in another browser or device. Those five pieces prevent the back-and-forth that wastes a day. If you can also point to the exact template name, do it.

Support teams need specifics. “The widget is missing” is not enough. “The widget is enabled for product pages, the script exists in source, it shows after consent in Chrome on desktop, but not in Safari on iPhone” is much better. That sentence contains the shape of the problem.

If your setup is custom, a developer may need to check the render hook, the data passed into the widget, or the order in which scripts load. If you use a custom build process, mention it. If you have more than one environment, mention that too. A staging site and a live site can behave differently for one simple reason: different build output.

Keep the page URL ready when you contact Astrina. Use the same exact page where the widget should appear, not a general homepage link, and include what browser you used. If you need help setting up or comparing settings, the astrina page can point you to the right plan and support path.

The cleanest handoff is a short list with one screenshot. Add the URL, the expected location, and the first console error. That is enough for most developers to start on the right layer instead of guessing.