Claude Code can help catch SEO regressions before a deployment by connecting the code you changed to the pages, metadata and responses that change will produce. The useful output is a finding with a route, evidence and a retest, rather than a generic assurance that the site is “SEO optimized.”
These 28 checks cover access, rendering, page identity, URL signals, discovery, images and performance. Use them against a defined release candidate. Mark a check unverified when Claude cannot inspect the necessary output; a source-code review is not proof of the deployed response.
This is a practical predeployment review, not a promise of indexing or rankings. Fixes, deployment and verification of the live release remain separate actions.
Give Claude Code a release scope and route manifest
Start in the repository containing the candidate change. Identify the release reference, the comparison reference and any relevant uncommitted changes. A shared layout or metadata helper can affect many routes even when the diff contains one file.
Review the current CLI options before starting:
claude --help
claude --permission-mode plan
The Claude Code CLI reference documents the permission-mode option. Anthropic's permissions guidance describes Plan mode as reading files and running read-only exploration without editing source files. Actual tool permissions still govern the session. A prompt saying “read only” does not replace those controls.
Use an installed, authorized setup. This workflow does not require an SEO plugin. If you want reusable instructions later, our Claude SEO skill-pack comparison explains their different dependencies.
Give Claude a small route manifest. The following is an illustrative JSON template, with example origins and a placeholder release reference:
{
"release_ref": "REPLACE_WITH_CANDIDATE_REFERENCE",
"candidate_origin": "http://localhost:3000",
"production_origin": "https://example.com",
"routes": [
{
"path": "/guides/indexing/",
"expected_status": 200,
"intended_indexable": true,
"expected_canonical": "https://example.com/guides/indexing/",
"expected_inbound_page": "/guides/"
},
{
"path": "/account/",
"intended_indexable": false,
"access_policy": "Follow the existing private-area design"
}
]
}
Add representative routes for each affected template, including a missing route and language or pagination variants where they exist. A preview can correctly point its canonical at a planned production URL. That new production URL may not work until deployment, so do not mistake its expected pre-release absence for a broken preview.
Paste this scope prompt, replacing the bracketed context:
Review the candidate release for SEO regressions.
Repository and comparison reference: [supply]
Candidate reference, including relevant local changes: [supply]
Route manifest and approved inspection tools: [supply]
Read the project instructions and inspect the relevant diff first.
Trace shared templates and configuration to the affected routes.
Do not edit, install dependencies, read credentials or deploy.
For each applicable check, return:
- route and intended behavior
- source file or configuration responsible
- observed output and evidence location
- PASS, FAIL, UNVERIFIED or NOT APPLICABLE, with a reason
- smallest proposed fix and the exact retest
Distinguish source evidence, built output and runtime observations.
Use only authorized existing build or preview commands.
If required tools or access are missing, describe the missing evidence
instead of inventing a pass.
Building and starting a preview can create files or execute project scripts. Inspect the existing commands and use the permissions already approved for that project. Keep the initial source review separate from those actions.
For a broader live-domain walkthrough, use the website launch acceptance audit. The checks below focus on what a coding assistant should establish about this particular release.
Check crawl access and rendered responses
Google's technical requirements separate access, a working response and indexable content. Use those distinctions when tracing a route from source code to the running candidate.
1. Public routes return the intended successful response
Ask Claude to identify the route handler, static output or rewrite responsible for each public URL. Request an important inner route directly, rather than reaching it only through client-side navigation.
For an authorized local preview, a GET request can expose both headers and HTML:
curl -sS -i "http://localhost:3000/guides/indexing/"
On Windows, use curl.exe if curl is a PowerShell alias. The example address must match your actual preview.
Retain the status and intended content. A successful build or a 200 response containing a login screen does not establish that the intended public guide works.
2. Missing routes behave like missing pages
Include a deliberately nonexistent path. Inspect both its response code and what the user receives. A router that serves the homepage for every unknown path can hide broken links behind apparent success.
Trace the fallback route and error handler. A genuinely missing page should normally return an appropriate 404 or 410, while a temporary server failure has a different meaning. Google's HTTP status documentation explains why a 200 error page can become a soft 404.
Record the missing-path response separately from the valid-route sample. They test different routing behavior.
3. Robots rules allow the intended public paths
Find how the production robots.txt is generated, including environment-specific rules. Compare its intended public path coverage with the release manifest.
Do not evaluate only the first Disallow line or assume all user-agent groups behave identically. Inspect the applicable rules and important resource paths. Keep deliberate restrictions where they belong.
Robots.txt controls crawling. It is not an authentication system or a reliable substitute for preventing indexing. A protected preview should remain protected during this review.
4. HTML and headers have the intended indexing policy
Inspect generated robots meta tags and any X-Robots-Tag response header. Trace global layout defaults, middleware and hosting rules that can override page-level intent.
A public guide accidentally inheriting staging's noindex is a different finding from an account page deliberately excluded from search. Check against the manifest rather than removing every exclusion.
Google must be able to crawl a page to see its noindex directive. Record conflicting crawl and indexing instructions as separate evidence, not interchangeable fixes.
5. The intended content survives rendering
Compare the route's source implementation, initial HTML and rendered output when an authorized rendering tool is available. Check that the main answer, product information or other essential content actually appears.
An application shell is not automatically unindexable: Google can render JavaScript. However, a browser-only API error, failed request or hydration issue can leave the intended content absent. Google's JavaScript SEO guidance explains the processing distinction.
If Claude only reads the component, label runtime rendering unverified. Do not describe an imagined browser result as observed.
6. Essential rendering resources are accessible
Review changes to asset paths, content-security rules and resource crawl restrictions. Check the specific scripts, styles and data needed for the public page, rather than treating every third-party request as an indexing prerequisite.
A page can return 200 while its important script or stylesheet fails. Preserve the failed resource URL, response and affected route. Compare the candidate's actual resource requests with its configuration.
Do not “fix” access by exposing private APIs. The acceptance question is whether the public page's required content and presentation can load through the intended public path.
Review page identity, content and structured data
Inspect at least two routes using each changed shared template. A metadata helper can look correct in isolation while returning the same values for every page.
7. Titles describe the correct page
Trace the title from route data through the shared layout to the output. Watch for missing values, stale brand names and fallback text appearing on unrelated pages.
Google's title-link guidance favors descriptive, concise titles. Use your editorial length target as a review aid, while checking the actual page promise and useful wording.
Evidence should include the route, resulting title and source of the value. Correcting one title in a fixture does not establish that the dynamic route family is fixed.
8. Descriptions remain relevant after template changes
Compare descriptions with the visible content and the intended reader task. A copied homepage description on a pricing or troubleshooting page can misrepresent what the visitor will find.
Inspect how an absent CMS field is handled. Distinguish a legitimate editorial omission from a template unexpectedly rendering “undefined” or a stale default.
Google can generate snippets from page content or descriptions. Verify relevance and output quality rather than treating a fixed character count as a guarantee of the displayed snippet.
9. The visible heading identifies the main topic
Ask Claude to inspect the heading structure after shared components render. Confirm that the page has a clear primary topic and that section headings describe their content.
Check for headings lost behind a loading state, a repeated site slogan replacing the page topic, or styling that visually contradicts the document structure. Use the hierarchy to help people navigate.
Record the relevant heading text and markup. Avoid turning a mechanical H1 count into the entire acceptance decision; the important question is whether this particular page communicates its subject clearly.
10. Distinct routes still provide distinct useful content
Compare the main content of representative routes, especially when a new parameter or CMS query controls which entry loads. A dynamic route can receive a new URL and title while accidentally rendering the previous page's body.
Ask Claude to trace the content identifier, data request and template output. Check for placeholder copy, empty collections and duplicated bodies where different content is intended.
Judge the reader's task and information provided. A word-count threshold cannot establish whether a short policy page is useful or whether a long repeated article is original.
11. Structured data parses and meets applicable requirements
For pages intentionally using structured data, inspect the generated JSON-LD and validate the appropriate supported type. Confirm required properties against that feature's current documentation.
Ask Claude to identify the generator and extract the actual output. A JSON parser can establish valid syntax; feature validation addresses additional requirements. A successful parse alone does not establish rich-result eligibility.
Use Google's structured data guidelines for the acceptance boundary. Mark this check not applicable when no relevant structured data is intended, rather than adding an unrelated type to satisfy the checklist.
12. Structured data matches visible, supportable facts
Review the values separately from syntax. A perfectly valid object can contain an invented review score, an obsolete price, a wrong author or a publication date that contradicts the page.
Compare every consequential claim with the visible content and its legitimate data source. Confirm that a shared layout is not attaching the same product or article entity to unrelated routes.
Keep a short discrepancy record: property, current value, visible source and expected correction. This factual review cannot be replaced by a validator's green result, and valid markup does not guarantee a rich result.
Reconcile URL and language signals
Use the route manifest as the reference. URL choices should agree across metadata, redirects, links and sitemaps, but each mechanism has its own purpose.
13. Canonicals identify the intended representative URL
Inspect the canonical in the candidate output, including any value added or changed during rendering. Check the origin, path and relevant language or pagination context.
A common regression is a shared default that points every guide to the homepage. Another is a preview hostname leaking into the production configuration. Trace the environment value and page-specific path instead of replacing all canonicals with one string.
A canonical is a preference signal, not a command Google must obey. Keep its value consistent with the intended representative content and the manifest's production origin.
14. Redirects preserve the meaning of moved URLs
Build a small old-to-new URL map for renamed or removed routes. Ask Claude to inspect the routing and hosting configuration, then verify the path through an authorized candidate environment where possible.
Record the redirect status, intermediate hops and final destination. Permanent moves generally call for permanent redirects; temporary behavior should retain its correct meaning.
Flag loops, avoidable chains and unrelated homepage destinations. A successful redirect to the wrong page is still a failed mapping. If the hosting redirect only exists after deployment, label that runtime result pending.
15. URL variants follow an explicit indexing policy
Review query parameters, filters, sort orders and slash or case variants affected by the change. Distinguish equivalent URLs from genuinely different landing pages.
For example, a tracking parameter and a filter that produces a useful distinct collection do not necessarily deserve the same treatment. Ask Claude to show the intended policy and all code paths that implement it.
Compare the resulting response, links and canonical where applicable. Do not generate a blanket rule that every parameterized page points to the homepage, or combine crawl blocking with an expectation that Google will read a new noindex directive.
16. Pagination exposes complete, separate pages
If a collection uses pagination or infinite loading, confirm that subsequent content has usable URLs and discoverable links. Inspect route data so page two does not accidentally repeat page one's entries.
Google's pagination guidance recommends separate URLs and sequential links, with each paginated page using its own canonical rather than canonicalizing the sequence to page one.
Record the first and a later page, their content and the link between them. Mark the check not applicable for a site without a paginated collection.
17. Language alternates point to real equivalent pages
For multilingual sites, inspect the actual alternate URL set rather than only whether an hreflang tag exists. Confirm the versions represent the same content in the intended languages or regions.
Google's localized-version guidance calls for fully qualified alternate URLs, self references and reciprocal relationships. Check that a translated detail page does not point to another language's homepage by default.
Compare the alternate set on both sides and keep it aligned with canonical intent. A missing translation should remain an explicit content gap, not an invented alternate. Single-language releases can mark this check not applicable.
Verify sitemap coverage and internal discovery
A page can be correctly implemented yet absent from the mechanisms that help crawlers find it. Check both the route inventory and the links generated by the release.
18. The sitemap covers intended public canonical pages
Compare the sitemap's URL set with the route manifest and relevant CMS publication states. Look for newly added public routes missing from the generator, as well as draft, private or obsolete URLs mistakenly included.
Check the production origin and path policy. If the sitemap is built statically, an otherwise successful build may still have used an incomplete content inventory.
Record the missing or unwanted URLs and the generator responsible. Google recommends including preferred canonical URLs, but sitemap membership does not guarantee indexing.
19. The sitemap is valid and describes real updates
Review the served sitemap or index and its referenced files. Confirm that XML parses, URLs are absolute, encoding is correct and any required escaping survives generation.
Inspect last-modification values separately from publication dates. If present, they should reflect meaningful content changes, rather than automatically giving every URL the build time.
This is different from coverage: a well-formed sitemap may omit a new page, while a complete URL list may be invalid XML. Preserve both membership findings and parser or response evidence. An unavailable candidate endpoint stays unverified even when its source template looks plausible.
20. Important routes have useful inbound links
Ask Claude to identify a relevant path to each new public page from an existing index, category, guide or navigation surface. Review template-generated links as well as literal links in source files.
Keep scope clear. Searching one component for the slug cannot prove that a route is linked across the whole site, and a crawl starting at the homepage cannot discover every orphan by itself. Compare the known route inventory with observed discovery.
Record at least one appropriate referring page for each important addition. An XML sitemap is useful context, but it does not replace a visitor's navigation path.
21. Navigation produces crawlable, meaningful anchors
Inspect the resulting link markup and resolved destination. A click handler on a styled card is different from a working anchor with a usable href.
Google's link guidance recommends ordinary anchor elements with href attributes and descriptive link text. JavaScript-generated anchors can still be crawlable when their final markup follows that pattern.
Check relative-path resolution on nested routes, empty destinations and image-only links without useful text alternatives. Evidence should show the referring route, actual href and destination. A navigation path can exist visually while its markup still needs correction.
Inspect images and performance regressions
Keep each finding tied to an affected route and resource. Image delivery, loading order, layout stability and interaction work have different causes, so one overall score cannot explain them all.
22. Important media URLs resolve to usable assets
Inspect image paths generated by the changed components, CMS fields and asset transformations. A path that worked in development may change after the production build or under a deployment subpath.
Check the actual response and displayed subject for important images. A 200 response containing an HTML error document is not proof of a usable image. Include responsive variants when a transformation generates separate URLs.
Record the referring page and asset destination together. That identifies where to fix the problem rather than leaving Claude with a list of broken image URLs.
23. Image text alternatives match their purpose
Review alt text in context. An informative screenshot should explain what matters in the image; a product photograph should describe the actual subject. Avoid repeating a keyword list on every image.
Google's image guidance explains the role of contextual alt text and surrounding content. Decorative imagery can require an empty alternative, while an image-only link needs an understandable accessible purpose.
Ask Claude to flag uncertainty when it cannot inspect the image itself. A filename alone is weak evidence for what a photograph or diagram contains.
24. Responsive images deliver an appropriate resource
Inspect source widths, srcset and sizes behavior, or the equivalent output of the framework's image component. Confirm that a small mobile image is not unnecessarily receiving the largest source file.
Compare the delivered resource's dimensions and bytes with its displayed role under a recorded viewport. Retain a usable fallback source where the markup requires one.
This check is about resource selection and payload. A file with an efficient format can still be far larger than the page needs. Avoid approving all images merely because their filenames end in WebP.
25. Main-content resources are discovered and prioritized appropriately
Identify the candidate's likely or measured Largest Contentful Paint element before changing loading behavior. Trace when its resource becomes discoverable and whether the component delays it unnecessarily.
The LCP optimization guide warns against lazy-loading the LCP image and explains resource discovery and priority. Do not mark every image high priority; that removes the distinction you are trying to create.
Save the relevant loading markup and, when authorized measurement is available, its request timing. An assumption about the hero image is a hypothesis until the rendered page supports it.
26. Layout space remains stable as content loads
Inspect image dimensions or aspect ratios, embeds, banners, fonts and placeholders affected by the diff. Check whether a late-loading component pushes the main answer or next action away from the reader.
CLS diagnostics distinguish initial-load shifts from problems that appear later in a page's life. A screenshot of the final settled page cannot show everything that moved before it.
Record the element, trigger and measurement or observed movement. Reserving space addresses a different failure from reducing image bytes or starting its download earlier.
27. Added JavaScript does not introduce avoidable interaction delays
Review new client-side dependencies, hydration work and event handlers on public pages. If the release changes a menu, filter or search control, include that actual interaction in the authorized diagnostic scope.
The INP optimization guide explains input delay, callback processing and presentation delay. Source inspection can identify suspicious work, but it cannot establish the latency a visitor experienced.
Keep lab observations separate from real-world Core Web Vitals. A load-only audit, a smaller bundle or a high score is not a field INP pass. Record unavailable interaction evidence honestly.
Check metadata isolation across requests
28. Shared state does not leak one page's identity into another
A shared metadata function deserves a check beyond inspecting one correct response. Ask Claude to trace mutable shared objects, cached metadata and the route or language values used to select an entry.
In an authorized candidate environment, request page A, then page B, then page A again. Repeat the relevant language variants if they exist. Compare the resulting title, canonical and structured-data identity with each page's expected values.
For example, imagine two guides whose individual source records are correct, but page B receives page A's canonical after a shared object is reused. That is a hypothetical failure, not an observed result from a particular framework. The problem is inconsistent request handling, rather than a missing field in either record.
Keep environment behavior in the evidence: development responses, built previews and deployed caching can differ. If the candidate cannot reproduce a hosting-layer behavior before release, record the source/configuration review and the specific live verification still required.
This check asks whether values remain correct across requests. It does not require every variant to have different metadata; intentional consolidation and pagination policies still apply. A useful pass shows repeatable output matching the manifest, with the relevant shared-state or cache logic identified.
Turn the findings into a release decision
Ask Claude for an evidence record, not an averaged “SEO readiness” score. A serious failure on one important public route should not disappear inside dozens of passing checks.
Use this copyable report structure:
SEO release review
Candidate reference:
Comparison reference:
Relevant local changes:
Candidate environment:
Intended production origin:
Inspection date and tool versions:
Route/template coverage:
Tools or access unavailable:
For each finding:
Check number:
Route:
Intended behavior:
Observed behavior:
Evidence level: source / built output / runtime
Evidence file, response or trace:
Status: PASS / FAIL / UNVERIFIED / NOT APPLICABLE
Source file or configuration:
Affected routes or template:
Proposed change:
Exact retest:
Remaining post-deployment verification:
Release recommendation:
Blockers:
Accepted limitations and owner:
Follow-up checks:
Here is an illustrative finding, using fictional paths:
| Field | Example |
|---|---|
| Check | 13, canonical destination |
| Route | /guides/indexing/ |
| Intended behavior | Canonical identifies that production guide |
| Observed behavior | Candidate output points to the homepage |
| Evidence | Saved candidate HTML and shared metadata helper |
| Decision | Fix before releasing this important guide |
| Retest | Rebuild the candidate, request the route and compare the canonical with the manifest |
Use FAIL for an observed mismatch, UNVERIFIED for missing evidence, and NOT APPLICABLE with a reason for absent features such as multilingual routes. A pass at source level must not be presented as a pass on a deployed server.
Prioritize broken public routes, accidental indexing exclusions, wrong destinations and missing essential content before cosmetic improvements. Preserve deliberate privacy and staging controls. After a fix, repeat the same check on the same candidate and expand the sample if shared code changed.
If you already use Screpy SEO MCP, completed-crawl findings can provide stored page, link and image evidence for the review. Keep the crawl's date and coverage visible. Those records describe the completed crawl, not an unpublished candidate or a release that has not been inspected yet.
Once deployment is authorized and completed, verify the real URLs separately. Hosting rules, environment values and caches can differ from a local preview. Google indexing and later search performance are subsequent outcomes, not something Claude can certify from this checklist.
This guide is based on current Claude Code and Google documentation reviewed on October 19, 2026. The prompts, manifest and finding above are reusable illustrations; no customer-site benchmark or firsthand deployment experiment is claimed.