An AI search visibility checklist for a real website.

1. Confirm the page can be reached

Open the final public URL and inspect its response. It should serve the intended page, not an error, a sign-in screen or a long redirect chain. Check both the original HTML and the rendered page when important text depends on JavaScript.

Review robots rules and indexing directives independently. Blocking a crawler in robots.txt can prevent it from reading a noindex tag. Pages that should stay private need real access controls; crawler instructions are not a security boundary.

• Record the final URL and HTTP status.
• Check robots.txt for rules affecting the important page.
• Check meta robots and X-Robots-Tag response headers.
• Confirm that critical text and links are present without requiring an account.

2. Make the preferred URL unambiguous

Pick a single public origin and use it consistently in navigation, canonicals and the sitemap. Redirect old hostnames to the matching new path. A canonical should represent the current page; sending every page's canonical to the homepage erases useful distinctions.

Check a few URLs with tracking parameters and older links. Readers should arrive at the correct page, and the declared canonical should identify its clean public version. Keep private reports and account routes out of the sitemap.

3. Answer a specific customer question

Give the page a clear purpose and a descriptive main heading. Put a concise answer near the relevant question, then expand it with conditions, examples and sources. Useful details often include supported integrations, delivery regions, compatibility, exclusions and the steps needed to start.

Replace vague superlatives with facts you can support. If you describe a free plan, state its limits. If a feature is in beta, explain what is available today. Do not publish invented testimonials, statistics or certifications to make the page look authoritative.

• Use one main heading that describes the page's job.
• Make subsection headings useful when read on their own.
• State the date or scope when information can become outdated.
• Link to the next relevant page using descriptive anchor text.

4. Match structured data to the page

Choose schema types that describe what is actually present: the organization, a page, an article or a breadcrumb trail. Check that names, URLs and other properties agree with visible content. Parse the JSON and inspect the rendered HTML after deployment.

Do not add an aggregate rating without real supporting reviews. Do not mark the whole paid product as free because it has one free feature. Structured data is a description of the page, not a place to hide stronger claims.

5. Keep the page usable on mobile

Check the layout at a narrow width. Navigation, forms, tables and primary actions should fit without horizontal page scrolling. Reserve space for media and serve appropriately sized images. A decorative background should not delay the text or prevent someone from starting the audit.

Use keyboard navigation and check visible focus indicators. Headings, links and labels should remain understandable without the visual layout. Performance measurements from a lab are useful for diagnosis; field data from actual visitors is a separate measurement.

6. Verify the release and track consistently

After deployment, check response headers, canonicals, sitemap links and the important content again. Save a before-and-after record of the technical findings. A pull request alone is not evidence that the public site has changed.

For answer tracking, keep the question set and configuration stable long enough to compare several runs. Inspect mentions and citations separately, record unsuccessful requests and avoid claiming that one site change caused every fluctuation. Combine these observations with business outcomes where you have reliable data.