How to Do a Website Audit That Produces a Fix List

A website audit should end with a prioritized repair list, not a dashboard score. For a publishing site, the practical questions are: can readers reach the content, can search engines discover the intended pages, does the site work on real devices, and can the operator measure what happens?

Use the workflow below for an initial operational audit. It combines a broad URL check with deeper reviews of representative pages; it is not a penetration test or a comprehensive accessibility assessment.

1. Define the scope and save a baseline

Choose the decision the audit must support: routine maintenance, diagnosing lost search traffic, repairing a broken signup flow, or preparing a migration. Record the production domain, audit date and deployed release if available.

Gather:

• Published URLs from the CMS or build output, XML sitemaps and a site crawl.
• Search Console indexing and search-performance reports.
• Analytics for landing pages and the reader actions that matter, such as newsletter signups.
• Recent deployment history and access to browser developer tools.

Do not rely on the crawl alone. Compare its discovered URLs with the publishing inventory to identify potentially unlinked pages. Verify their internal links and the crawler’s settings before treating them as orphan pages.

For manual testing, choose examples from each template: homepage, category, article, search, signup and error page. Include high-traffic pages, recently published pages, older content, and pages with ads or embeds. Record which URLs were tested; a sample is not proof that every page works.

2. Check delivery, discovery and indexing

Use a crawler to export status codes, redirect targets, titles, canonicals, robots directives and internal links. On a small site, a URL spreadsheet and manual inspection can cover the same checks.

Look for:

• Published pages returning errors or redirecting to the wrong destination.
• Broken internal links, redirect chains and missing assets.
• Missing-page routes that display an error but return 200.
• Unexpected noindex, conflicting canonicals, or production links pointing to staging.
• Sitemap entries that disagree with the intended public URL inventory.

An intentional 404 is not automatically a defect. The issue is whether an existing page is broken or readers are being sent to a removed URL. Google also distinguishes successful responses from useful content: an error page returning 200 can be treated as a soft 404. Persistent server errors can affect crawling and indexing. See Google’s HTTP status guidance.

For important pages missing from search, inspect the URL in Search Console. Compare the indexed record with a live test, and check the Google-selected canonical in the indexed data. A successful live test does not prove that the page is indexed or will appear in search results. Google documents these distinctions.

Keep crawling and exclusion separate: robots.txt is not a reliable way to keep a page out of Google. It can also prevent Google from reading a page’s noindex directive. Use the appropriate staging exclusion controls, following Google’s robots.txt limitations.

3. Measure loading and test reader journeys

Run PageSpeed Insights on representative URLs for mobile and desktop. Save the reports, not just the scores.

Separate two types of evidence:

• Field data: observed Chrome user experiences over a trailing 28-day period. Check whether the report describes the URL or the whole origin.
• Lab data: a controlled test used to investigate loading problems.

A low-traffic page may have no field data; that is missing evidence, not a passing result. Lab and field measurements can differ, and a good lab score does not guarantee good real-user experience. PageSpeed Insights explains the scope and limits.

In the browser, follow an actual journey: open a category, read an article, use an embed, and complete a signup. Test narrow screens and slower connections. Inspect failed requests, console errors, oversized images, delayed fonts and third-party scripts. For font-specific problems, use the two-pass font loading audit.

Check keyboard navigation, visible focus, zoom, contrast, image alternatives and form labels. These are useful first checks, but passing them does not establish accessibility conformance; W3C explicitly warns that basic checks are not exhaustive.

4. Review content, tracking and operational controls

Read the sampled articles against the task promised by their titles. Can the reader act without searching again? Check factual accuracy, source relevance, outdated instructions, unsupported claims, authorship and overlapping pages. Assign an action—keep, update, consolidate or remove—with a reason. Low traffic alone is not a removal criterion. Google’s content self-assessment provides useful questions about originality, completeness and trust.

Test measurement separately from the interface. For a signup, verify the success state, the downstream subscriber status and the expected analytics event under the applicable consent conditions. If the flow requires email confirmation, test that step too. A click event proves a click, not a completed subscription.

Review HTTPS behavior, staging access, administrative permissions, third-party integrations, backups and rollback instructions. Escalate suspected vulnerabilities to a qualified security review rather than treating a clean automated score as assurance.

5. Prioritize repairs and verify the deployed result

Create one issue per root cause, with affected URLs or templates attached:

Field	What to record
Evidence	URL, timestamp, screenshot, response or report
Impact and scope	Blocked reader task; affected pages or template
Action	Specific repair and named owner
Verification	Observable pass condition and retest method

Fix access failures, exposed private content and broken reader actions first. Then address shared-template defects and high-impact content problems. Keep speculative improvements separate from reproducible faults.

Hypothetical example: the article template sends signup submissions to an obsolete endpoint. Record the failed request and affected template. After deployment, use a controlled test address to complete the signup, including confirmation if required. Verify the expected subscriber status and, with analytics consent granted, one completion event—not merely that the error disappeared.

Retest the original failing URLs and unaffected examples from the same template. Use consistent lab settings and visual regression checks where appropriate. Close an issue only when its pass condition is met; track later indexing or field-performance changes separately from the immediate deployment check.