How to audit a website before publishing
Before publishing, audit a representative set of public URLs, inspect robots.txt and the sitemap, verify titles, headings and canonicals in returned HTML, and repeat the check after deployment. Keep the result as a dated release record.
Updated 7 October 2026. Keep the output and the verification step together.
Steps
- List the URLs and templates changed in the release.
- Audit the public staging or preview host only when its access policy matches the release; otherwise test the production URL after deployment.
- Check the returned title, description, heading, canonical, robots directives, language and viewport.
- Review robots.txt, sitemap references and redirects.
- Publish, fetch the same representative URLs and compare the evidence.
- Keep the report and any exceptions with the release notes.
Choose representative pages
Include one URL for each changed template and one important conversion page. A homepage-only check will not catch a bad article template or a directory-level canonical.
Check what users and crawlers receive
The source response matters. Inspect the final URL after redirects, the text in the HTML and the directives that apply to the page. A browser view can hide a missing server response behind JavaScript.
Keep exceptions visible
A preview environment may intentionally block crawlers. Record that as an environment difference rather than a production finding, then run the same check on the live host after deployment.
Repeat after release
A passing pre-publish check is not evidence that the deployment completed correctly. Fetch the final URLs again and retain the before and after values.
Questions
Should I block a staging site?
Usually yes, but record the difference and test production after release. Do not treat a blocked preview as proof that production is blocked.
Does this replace Search Console?
No. It checks public technical responses and should be paired with search tools when indexing matters.