SEO QA for website releases

Define what the release can change

Start with the deployment manifest: templates, content exports, PHP includes, server rewrites, headers, edge rules and third-party components. A small navigation change can affect discovery across every page. A content-only release can still introduce invalid markup or duplicate metadata if the publishing pipeline transforms fields. Map each changed component to the public behaviours it controls.

Give the release an identifier and name an engineering owner, SEO reviewer and deployment decision-maker. Record the candidate build, intended production configuration and dependencies that ship separately. Otherwise, a passing test can refer to a different artefact from the one eventually deployed.

Write the expected difference before comparing output. A redesign might intentionally change headings while preserving meaningful copy and links. A route change might intentionally replace a successful response with a redirect. Use the technical SEO audit checklist to identify relevant surfaces, then narrow the release scope to concrete risks and their affected URL populations.

Choose samples by route and publishing state

Build a small mandatory sample covering each changed rule, then expand where consequences justify it. Include the home page, section pages, ordinary articles, unusually long content, sparse records, pagination if present, an old URL and a deliberately missing URL. Select pages by behavioural differences rather than choosing only the most visited routes.

For a static PHP site, check extensionless public routes alongside any directly reachable PHP paths and slash variants. Decide which should redirect, serve content or fail. Include pages using shared includes even when their content files did not change. A global head include can alter canonical URLs across otherwise untouched pages.

Preserve intentional exclusions as controls: a private preview must remain protected when public pages become accessible. Record the expected status, destination, canonical, content marker and discoverable parent for each sample. Note untested combinations explicitly. A sample demonstrates coverage of selected mechanisms; it does not establish that every generated route behaves correctly.

Capture a concrete evidence checklist

Save enough evidence for another reviewer to reproduce the decision. Screenshots help assess layout, but cannot establish response headers or redirect behaviour. Retain machine-readable outputs alongside a short interpretation and record request time, host, build identifier and relevant browser conditions.

• Inventory: sampled URL, page type, intended publication state and changed component.
• Transport: initial status, redirect hops, final URL, response headers and cache indicators.
• Document: title, description, canonical, robots directives, primary copy and heading structure.
• Discovery: source page, actual link destination, sitemap membership where intended and navigation context.
• Execution: original HTML, browser output where needed, failed resources and console errors.
• Decision: expected output, observed difference, severity, owner and unresolved limitation.

Store before-and-after observations under identical conditions where possible. Use actual GET responses when the body matters; a header-only request cannot verify the document. Preserve relevant exceptions rather than reducing everything to one pass percentage. Ten correct pages do not cancel one public route accidentally receiving a restrictive directive.

Validate routing and indexing controls together

Test routing before analysing document metadata. Confirm that valid routes resolve, intended permanent moves reach the correct destination and missing records do not masquerade as ordinary successful pages. Inspect every redirect hop, because a correct final page can hide an intermediate loop, unnecessary detour or incorrect host transition.

Read both robots meta tags and X-Robots-Tag headers. Check the deployed robots.txt against the relevant public paths. Blocking crawling is not a substitute for a readable noindex instruction: Google needs access to encounter that instruction. Keep previews protected using the chosen access controls rather than casually removing every restriction for launch.

Check canonical targets against the intended production host and route. Google treats canonical annotations as signals, so acceptance should verify your emitted preference rather than demand a particular Google-selected URL. Look for staging hosts, repeated home-page targets and contradictions between annotations, redirects and links. The canonical tags guide explains how to investigate those conflicts beyond the release gate.

Test content, links and experience on direct entry

Open representative pages directly in a fresh session. A PHP-rendered document should contain the expected article without depending on a previous navigation. Where JavaScript enhances navigation or content, compare the original response with browser output. An initially restrictive robots tag should not depend on script removal; Google may skip execution after encountering noindex.

Inspect navigation as markup. Important destinations should use resolvable anchors with href attributes, with useful text and working targets. Compare heading order, content completeness and contextual links after any template change. A visually identical clickable element can lose its crawlable destination during a component refactor.

Use repeatable laboratory performance checks to identify likely regressions, keeping device and network settings consistent. Good Core Web Vitals thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1 at field p75, assessed separately for mobile and desktop. A launch-day lab run cannot certify field performance. Plan follow-up through performance regression monitoring.

Resolve competing explanations before blocking deployment

When staging and production disagree, list plausible mechanisms. Missing copy could reflect an incomplete content export, a wrong template branch or a failed enhancement request. An unexpected canonical could originate in configuration, cached output or a URL-normalisation error in the checker. Avoid assigning every discrepancy to the developer’s latest code change without discriminating evidence.

Compare an affected page with an unaffected control sharing the suspected component. Inspect the source record, rendered document and responsible configuration in sequence. Change one request condition at a time. If only returning sessions fail, investigate storage or caching; if the raw response is wrong for everyone, start upstream of browser execution.

Classify findings as confirmed defect, intentional change, test fault or unresolved observation. An unresolved high-consequence control deserves an explicit release decision, while a minor extraction error should be corrected in the checker. Document the next test that would separate the remaining hypotheses instead of labelling an uncertain mechanism as proven.

Illustrative worked example: a leaked preview header

Illustrative worked example: a fictional editorial site releases a revised PHP head include and an edge rule for preview pages. Its sample contains twelve public articles, two section pages, a preview and a missing route. The numbers describe an invented test design, not a client engagement or measured commercial result.

All staging documents look correct, but production smoke checks find an unexpected noindex header on public articles. Three explanations are tested: the include emits the directive, the edge rule matches too broadly, or stale cached responses retain an earlier header. Raw origin responses lack the header, while fresh edge responses include it on the affected path prefix.

The deployment owner disables the incorrect edge rule and restores its previous scoped version. Public samples then lack the unwanted directive, while the preview remains inaccessible without authorisation. This supports the edge-rule diagnosis. It establishes a technical correction under the tested conditions, without establishing when Google will revisit the affected URLs or whether any search outcome changed.

Set implementation acceptance and rollback criteria

Acceptance criteria must describe observable output. Require the sampled public routes to return their agreed statuses, canonical targets and content markers; require preview restrictions to remain effective; and require important links to resolve to intended destinations. Set an explicit zero-tolerance gate for accidental public noindex, staging-host canonicals or missing primary content on protected samples.

Assign each blocker a reproducible request and an owner. Document accepted lower-severity exceptions with expiry dates. A reviewer should be able to distinguish a waived issue from an unexecuted test. Expand route checks for global rewrite changes, because a few templates cannot represent every historical URL mapping.

Prepare recovery at the responsible layer. Reverting PHP code will not necessarily revert edge rules, content exports or cache entries. Check that the previous application can read the current content format before rollback. Reversal can restore an old routing defect or remove newly published content, so rehearse the bounded procedure and verify both repaired behaviour and preserved exceptions afterwards.

Verify production and hand over unresolved observations

Run smoke checks against the actual public host immediately after deployment, with the release identifier attached. Test both fresh requests and relevant returning-session behaviour. MDN distinguishes no-cache, which requires revalidation before ordinary reuse, from no-store, which prevents storage; neither should be treated as a universal purge command for existing cached output.

Compare production evidence with the approved candidate and investigate mismatches before closing the release. Give every deferred check a named owner and review condition. Search Console observations can support later investigation, but a historical crawl record should not replace verification of the response currently being served.

Turn confirmed failure modes into permanent regression tests and connect urgent production signals to technical SEO monitoring. Keep technical acceptance separate from search outcomes: successful QA cannot guarantee indexing, rankings or AI citations. Its practical value is a reviewable deployment decision and a shorter path from an observed defect to a safe correction.