Choose the script entry point for the framework and router your public website actually uses. Loading a script once is separate from applying the right changes after client-side navigation.
These steps use the setup supplied in your current account. A platform’s ability to accept custom code does not establish support for every AnswerMetrix fix. Browser, native and server-side delivery have separate requirements.
Before you begin
- Use the installation supplied for the correct website in your current AnswerMetrix account. If the route or download is unavailable, ask the team to confirm support before changing the site.
- Confirm platform version, account role, code access and CSP/consent requirements with the site maintainer.
- Keep a recovery copy or reviewed source-control change, and identify existing SEO scripts/plugins that manage the same fields.
React or Vue with Vite
- 1Copy the correct website’s snippet from AnswerMetrix.
- 2Open the root index.html used by Vite; it is normally at the project root, not public/index.html.
- 3Add the snippet once in the document head and deploy through the normal reviewed build process.
Next.js or a server-rendered headless site
- Next.js App Router: use next/script in the shared public layout, preserving the supplied source and data attributes. Confirm the loading strategy with the release’s installation instructions.
- Next.js Pages Router: use the router’s documented shared script setup; do not paste an App Router example into a Pages Router project.
- Vue/Nuxt or another headless framework: use its maintained head/script configuration for the installed version. Have the site maintainer adapt the supplied snippet rather than inventing a new endpoint.
Test direct loads and client navigation
- 1Open an important public route directly and confirm the script loads once.
- 2Navigate to a different route without reloading. Inspect the URL, page metadata and intended page-specific change.
- 3Reload the second route and compare the result. Check for a head manager that overwrites or duplicates metadata.
- 4If navigation is not supported by the release’s embed, stop rollout on that route and ask for a supported integration.
Keep essential content in crawlable server/static output where possible. A browser mutation does not establish that a crawler received the same content. Public sitemaps and links aid discovery; they do not expose private pages.
Check installation before delivering a change
- 1Open the published domain and representative public pages. Confirm the intended snippet request or plugin connection succeeds, with the correct site selected.
- 2Check for duplicate scripts, blocked requests, stale caches and console errors. For client navigation, check a second page without a full reload.
- 3Review one eligible, factually correct proposal and its route requirements. Authorize it only through the current account’s supported controls.
- 4Inspect the delivery record and the separate live-page result. For crawler-dependent changes, inspect raw HTML or the supported server-rendered response; a browser DOM change is different evidence.
A loaded script or plugin check-in establishes connection evidence. It does not prove that a fix was delivered, indexed or cited. If the exact expected live signal is unavailable, keep the result unverified and resolve it before expanding the batch.
If the setup does not work
- Check the published domain and page coverage, rather than only the editor or preview.
- Check role/plan access, the site identifier and the browser network request. Preserve the observed error for support.
- Check cache, CSP and consent behavior; ask the maintainer to authorize the required configuration instead of disabling controls globally.
- Avoid duplicate installs or repeated scans while diagnosing the same connection problem.
Remove or recover the installation
Revert the shared script integration and deploy the reviewed correction. Test a direct request and a client transition to confirm removal. Revert any separately published native or edge changes through their own route.
Official platform guidance
Platform documentation reviewed on 3 October 2026. Menu names and access can change; follow the documentation for your installed version.



