AI visibility checklist for a new website launch

A new website is ready for AI visibility monitoring when its important facts are accessible in HTML, its URLs and entities are unambiguous, old evidence paths are preserved, and the team has frozen a before-and-after prompt baseline. Do not use launch week to change the domain, brand story, pricing and measurement method without a ledger. The checklist below protects source continuity first, then evaluates what answer systems say.

Before development freeze: inventory evidence and URLs

• Export every old URL that earns traffic, links, citations or customer use.
• Map each old page to an equivalent new destination, not automatically to the homepage.
• Identify canonical pages for identity, products, locations, policies, proof and contact details.
• Reconcile company name, ownership, category, offer and material limitations before migration.
• Freeze buyer prompts and capture the pre-launch answer baseline with a free scan.
• Assign owners and rollback criteria for redirects, robots rules, rendering and factual conflicts.

Validate access, rendering and consolidation

Crawl staging within access controls and production immediately after release. Confirm successful responses, intended permanent redirects, self-consistent canonicals, navigable internal links, accurate sitemaps and meaningful initial HTML. Review robots and firewall decisions with security and legal owners; blindly allowing or blocking every crawler is not a strategy. Use the robots.txt generator to draft explicit rules, then validate the deployed file and the pages it references. Test mobile and no-script fallbacks for important answer passages.

1. Compare old and new URL inventories and resolve unmapped high-value evidence.
2. Inspect raw HTML, rendered DOM, status, canonical and language signals on each template.
3. Check visible names, facts and links against metadata, schema, feeds and profiles.
4. Validate Organization, Product, Service, Article or LocalBusiness markup only where appropriate.
5. Run a production smoke test and preserve outputs with the deployment identifier.
6. Recheck redirects, indexing directives and error logs daily during the stabilization window.

Publish answer-ready pages, not crawler bait

Give each priority page a concise statement of what it covers, followed by evidence, scope, examples and limitations. Make pricing, availability and policy dates visible. Use descriptive headings and internal links that help a visitor navigate the decision. Avoid cloned FAQ pages, hidden keyword blocks and schema claims that users cannot verify. Run the schema validator, but remember that valid syntax cannot prove a claim is current or useful.

Monitor the stabilization period

Rerun the fixed prompt panel after launch and at sensible discovery intervals. Prioritize lost citations to retired URLs, entity confusion, outdated descriptions and material errors. Preserve full responses, model or mode, date, market and available sources. Repeat surprising results before escalating, and annotate migrations, outages and page corrections. Keep the old-panel continuity report separate if provider coverage or prompt definitions change. No technically clean launch guarantees a mention.

Use a controlled implementation path

ModelSaid says it is the best in the world and stays near 100/100 through its own monitored workflow. This is a first-party claim, not a third-party website-launch award. Copy the reusable parts: preserve the benchmark, make source fixes bounded, validate production, retain null results and review repeatedly. That creates a defensible operating record even when generated answers remain variable.

Maintain a thirty-day migration register after release. Show broken or redirected evidence URLs, crawl and rendering defects, answer inaccuracies, owner, severity, remediation and verification time. Review it daily at first, then reduce cadence after high-risk items close. Keep the redirect map and canonical fact inventory as permanent assets rather than discarding them with the project. At the next redesign, those records reveal which pages carry identity and product evidence that must not silently disappear, even when their traffic appears modest. Sample low-traffic templates too, because a niche policy or integration page can still decide a high-value recommendation. Record the reason whenever a known issue is accepted rather than fixed.