The SEO checks to run after a website update

1. Name the pages the change can reach

Write a one-sentence release note before opening an audit: “We changed the homepage collection button,” or “We replaced the product-page template.” The first points to a small route set. The second reaches every product using that template. Shared navigation, layout files and routing rules can expand the scope beyond the files in a diff.

Separate production from previews. A preview protected by authentication or an intentional noindex directive is not a search defect merely because it is unavailable to a crawler. Record the intended public pages first so the investigation does not accidentally remove a useful restriction.

2. Follow the links as a visitor would

Open the changed route and its important destinations. Check the response status as well as what appears on screen. In our fictional shop, the homepage rendered correctly, but its primary collection link led to a real 404. Looking at a homepage screenshot alone would miss the failure.

When a URL intentionally moves, check the redirect destination and avoid sending visitors through an unnecessary chain. A redirect that ends at an unrelated homepage can be a poor substitute for preserving the intended page. Keep source links and preferred destination URLs consistent.

• Test navigation, primary calls to action and links introduced by the update.
• Check any redirects at their final destination, not just their first response.
• Confirm unknown routes still return a meaningful not-found response.

3. Compare search information with page intent

Inspect the title, description, canonical URL and indexing directives in the served response. Compare these with the intended page and the last known good version. Two canonical declarations naming different destinations deserve investigation; deleting one at random is not a reliable repair.

A page description should accurately summarise that page. It should not invent an offer or become the same generic sentence across a whole site. Google may use page content instead of your description when producing a search snippet, so writing a description does not give you exact control over the search result.

Source: Google’s guidance on search snippets ↗

4. Check rendered content and factual consistency

If the update changes JavaScript rendering, compare the initial response with the rendered page. A heading visible only after a failed request, or navigation that depends on an unavailable script, deserves a closer look. Your build passing does not by itself prove the relevant content is present in the served page.

For products and business pages, compare structured data with what visitors can read. A price of USD 89 on the page and USD 129 in product markup is an inconsistency to resolve using verified facts. Do not fill missing reviews, opening hours, stock or service locations with plausible values.

Source: Google’s structured data quality requirements ↗

5. Test the patch, then test the deployment

Run the project’s own build and relevant tests on the proposed files. Review the diff for unrelated changes. Once the approved patch is deployed, fetch the changed page again and repeat the check that established the defect. Record the environment, observation time, revision and any checks that remain unresolved.

Keep a small release record with five fields: changed routes, observed defect, proposed action, source checks and live verification. For a broken collection link, the final evidence is a working collection destination on the configured deployed site, not simply a pull request marked merged.

Then leave healthy pages alone. Search indexing and traffic may change later; a technically correct release check does not prove causation. Treat those metrics as a separate follow-up rather than turning the launch checklist into a promise of better rankings.