Why a website report widget does not appear

If an IssueProbe report widget does not appear, check the page's installed snippet, the exact verified origin, and website readiness before changing your security policy. Then check whether an integrity hash belongs to a rolling script address, whether the launcher is collapsed, or whether your own page has hidden it. These checks distinguish a loading failure from a visibility problem without asking visitors for private browser data.

Start with the page that actually fails

Open the affected public page, not only the template or preview where you added the widget. Confirm that the page includes the installation snippet for the intended website. A template change does not prove that every deployed page includes it.

Record the page's origin and when you checked it. An origin consists of the scheme, host, and port. A main domain, a subdomain, and a preview domain are not interchangeable.

In browser developer tools, check whether the widget script request succeeds and whether the browser reports a blocked script or integrity mismatch. Keep this inspection local. Do not paste complete request headers, cookies, query values, or response bodies into a report.

The installation guide explains how to obtain the snippet. The API reference documents the install operation and its rolling and pinned choices.

Match the page to an exact verified origin

The public widget key identifies one website; it is not proof of domain control. IssueProbe also checks the exact verified request origin. Copying a working snippet from a different domain does not authorize the new domain.

Check the website's registered origins. If the affected origin is pending, publish the exact public proof at the HTTPS address shown in website setup, then select Verify. A redirect to another domain does not complete that proof.

Do not solve an origin failure by sharing an account credential or by trying to spoof a request header. Neither is part of widget installation. Follow how a website proves control of its origin for the public file requirements.

Also check website readiness. IssueProbe requires verified origin control and ready repository access for normal report intake. If setup shows a repository problem, correct the registered connection and complete a fresh read-access check. Adding a script to the page does not finish those setup steps.

Check rolling and pinned scripts separately

IssueProbe provides two addresses for the widget bundle. Their update behavior differs, so the integrity setting must match your choice.

| Installed choice | What to check | |---|---| | Rolling address | Do not add an integrity attribute. The bundle can change at a release, making an old hash invalid. | | Pinned address | Use the complete provided pinned snippet, including its matching integrity value and cross-origin attribute. | | Old pinned snippet | Obtain and install a new pinned snippet when you want a newer widget correction. A pin does not update itself. |

A browser that rejects an integrity mismatch will not run the script. That can explain a widget that disappeared after a release even though the page still contains a script tag.

Do not combine a rolling address with a hash copied from a pinned snippet. Choose one installation mode and use its complete snippet. If your policy requires integrity, retain that requirement and use the pinned mode rather than weakening the policy.

Distinguish hidden from not loaded

A loaded widget need not look like the full labeled launcher you expected.

• A compact launcher is icon-only at every width. The full launcher also becomes icon-only on small screens.
• A visitor can move the launcher to another corner on their device.
• A visitor can collapse it to a small tab at the screen edge. Selecting the tab expands it again.
• Your page can temporarily hide the widget through its documented host control API, for example while a modal is open.

Inspect all four corners and the screen edges before concluding that loading failed. If your page hides the widget for a modal, check that it also shows it again when the modal closes. A page load starts visible, but your page can then hide it again.

Do not rely on host-page CSS to hide or restyle the widget. IssueProbe isolates its interface from those rules and provides explicit visibility controls. Their behavior is documented in the API reference.

Correct placement without changing report collection

A top-corner launcher can cover a fixed header. Choose a different default corner or use the owner placement offsets, each from 0 to 160 pixels, to move it clear of your navigation.

Test at a narrow viewport as well as desktop width. Check that the launcher and collapsed tab remain reachable, and that opening and closing the panel works with a keyboard. Treat placement and appearance as separate from evidence settings: moving the launcher does not justify collecting more browser information.

For evidence limits and screenshot consent, consult the widget privacy rules.

Verify the report path after the launcher returns

A visible launcher proves only that the interface is present. Complete the setup check with a test report from the exact intended origin, using harmless text and no sensitive screenshot. Confirm receipt, then find that report in the owner's dashboard.

IssueProbe stores a report even when monthly investigation quota is exhausted. Receipt does not promise an investigation, a known cause, a visitor reply, or a fix. Keep those outcomes separate when deciding whether installation works.

If the widget still fails, preserve a short diagnostic record: the affected origin, the script mode, the browser's safe error summary, website readiness, and which checks you completed. That gives the next reviewer a specific starting point without a private browser export.