SEO Audit Checklist 2020

I start every audit with the same five checks. Anything beyond these is usually a waste of time until you fix the basics.

1. Crawlability. Open robots.txt and check that valuable pages are not blocked. Look for disallowed paths that might hide product pages or blog posts. Then check server responses – 200, 301, 404, 5xx – for a sample of URLs. I use a crawler to spot any blocked resources like CSS or JavaScript that Google cannot access. If a page returns a 200 but the server blocks critical assets, you might as well have a 404.

2. Indexation. Pull a list of indexed pages from Google Search Console. Compare it to your sitemap. I often find that 30% of sitemap URLs are not indexed because of a noindex directive or a soft 404. Run a site: search for a few important pages to confirm. If a page is not indexed, check its canonical tag and meta robots.

3. Sitemaps. Your XML [sitemap](/sitemap/) should contain only canonicals, not every URL variant. Submit it in Search Console and monitor the “Indexed” count. I once saw a client with a sitemap that included 10,000 URLs, only 2,000 of which were indexable. The rest were parameterised duplicates.

4. Canonicals. Check a dozen pages across different URL patterns: www vs non-www, HTTP vs HTTPS, trailing slash, UTM parameters. Use a [canonical tag](/canonical-tag/) to point to the preferred version. I still see sites where the canonical points to a 301 redirect – that kills the link equity.

5. Internal linking. Crawl the site and look for pages with no internal links. These are orphan pages. Also check for broken links and redirect chains longer than one hop. I aim for every content page to have at least three internal links from other pages in the same topic cluster. This is where [technical SEO](/technical-seo/) and site architecture meet.

After these five, I move to speed and [Core Web Vitals](/core-web-vitals/), then [mobile rendering](/mobile-seo/). But I never do those until the first five are clean.

I stop when I have clear, actionable fixes that will move the needle. That usually means the first five checks are done and I have a list of no more than ten critical issues. If I am still finding minor problems after two hours, I close the crawler. Perfect is the enemy of shipped.

A counter-argument: some auditors say you must check every page. I disagree. If you have 50,000 URLs, a sample of 200 will reveal the same patterns. I use a crawl depth of 3 and a cap of 1,000 URLs. That catches 95% of issues. The last 5% are usually edge cases that do not affect rankings.

Another rule: if the robots.txt is blocking the entire site, fix that first. Then re-crawl. Do not waste time on anything else until the site is accessible. I once spent an hour analysing page speed before realising Google could not even crawl the homepage. That was embarrassing.

I also stop when the data contradicts the tool. For example, if a crawler says 90% of pages have duplicate meta descriptions, but Search Console shows no indexation issues, I move on. Tools are wrong. The search engine is the only truth.

Finally, I stop when the client (or my own site) cannot fix the issue in the next sprint. I prioritise based on impact: a blocked resource that affects 10,000 pages gets fixed before a missing alt tag on the about page. If you have no budget for a fix, do not spend time documenting it. Move to the next problem.

I used to think an audit needed to be exhaustive. I would crawl every page, log every warning, and produce a 50-page PDF. That was a mistake. Clients never read it. I spent days on things like “missing alt text” and “low word count” while ignoring the robots.txt that blocked half the site.

Specifically, I once ignored the [robots.txt](/robots-txt/) rule for a big e-commerce site because the “Disallow” directive looked like it only applied to admin pages. It actually blocked the entire product catalogue. I had done a full crawl and found 200 errors, but never noticed that 80% of the pages were returning a 403. The audit was useless. That taught me to start with the single most important file.

Another thing I got wrong was treating structured data as a priority. I spent hours validating [schema markup](/schema/) for a blog that had no traffic. The pages were not even indexed. Now I check indexation before touching any schema. It sounds obvious, but I had to learn it the hard way.

I also used to recommend perfect internal linking structures with strict silos. That fails on most sites. A better approach is to fix broken links and orphan pages, then let topic clusters emerge naturally. I still get it wrong sometimes, but I catch myself earlier now.