Article
How to install a website report widget
Place one report widget snippet on your page, choose a rolling or pinned script address, and keep it inside a strict security policy.
A report widget gives each visitor a short path from a visible problem to a useful record. The installation itself is one small script line on your page. The decisions that matter are where the file comes from, where the launcher sits, and how the widget behaves inside a strict security policy. This guide walks through each choice.
Place the snippet once
After you register a website and verify its origin, the product returns one ready installation line that carries your public widget key. Paste that line into your page template, near the end of the body, and the launcher appears on every page that includes it. The line loads asynchronously, so it does not block your own page load.
The widget key identifies one website. It grants no account, repository, report-list, or billing access, so it can sit in public page markup. The server still checks the exact verified request origin, so a copied key from another site receives no configuration and cannot create a report for your website.
Choose the rolling or pinned address
The same widget bundle is available at two addresses, and the choice has a real consequence.
The rolling address uses a short cache, so a product correction reaches every installed site without any change on your page. Never add a subresource integrity attribute to the rolling address. The bundle changes at each release, the hash stops matching, and the browser then refuses to run the script. The widget disappears from your site until you update the hash.
The pinned address is derived from the exact bundle content and is served with a long immutable cache. Use it when your policy requires an integrity attribute, and copy the provided snippet that already carries the integrity hash and the anonymous cross-origin attribute. A pinned install does not update itself, so read the install route again after each release and replace the snippet to receive a correction.
Place the launcher where visitors find it
The launcher supports all four viewport corners, and a visitor can drag it to another corner or collapse it to a small edge tab on their own device. You set the default.
Two appearance settings shape the first impression. A full launcher shows the label and icon, and an icon-only compact style saves space at every width. One accent color applies to the launcher, the collapsed tab, and the primary panel button, while the panel text keeps its own readable colors. The label color is chosen automatically from the accent, so you never pick a foreground.
The launcher paints above normal page content, so a top corner can cover a compact fixed page header. Move the default to a bottom corner, or add a small vertical offset of up to 160 pixels, when the launcher sits over your own header or footer.
Keep a strict security policy
The widget renders inside a shadow boundary and does not change host-page styles. Its styles are adopted through the constructed stylesheet interface rather than an injected style element, so a strict style policy needs no hash and no unsafe inline value for the widget.
The widget cannot be hidden or restyled by host page styles. That armor is deliberate, because it keeps careless or hostile page rules from breaking the report channel. Control visibility from your page instead. The script defines a small host control object with hide, show, open, and close members. Hide the widget while your own modal is open, then show it again, and open the panel from your own report link.
Know what the widget collects
The evidence categories are fixed and bounded: a visitor-approved screenshot with a preview, bounded console errors and warnings, failed or slow request metadata, and metadata-only browser state that records names, presence states, and sizes without values. You can disable a category, but no setting can add a value field or an undocumented field. The exact rules are on the widget privacy page, and the practical value of each category is explained in what browser evidence helps investigate a website problem.
After installation, send a test report and read the example report to see how the visitor statement, the safe evidence, the conclusion, and the unknown facts reach review. The complete install route, with both snippets and the host control members, is in the API reference.
Try the complete report review flow.
Start with one website and no payment card.