Technical SEO Checklist

The only checklist that matters is the one you can run in under 30 minutes. Anything longer and you will skip it. I start with crawlability. I open [robots.txt](/robots-txt/) and look for lines that block Googlebot from CSS, JavaScript, or images. In my last audit, 12% of sites accidentally blocked their own resources. That breaks rendering and can stop pages from being indexed. Next, I check the [sitemap](/sitemap/) in Search Console. If it reports valid URLs but the count is far below the number of pages I expect, I look for missing pages or incorrect exclusions.

Then I move to indexability. I run a crawl and filter for pages with noindex tags. I ask: should these really be excluded? If yes, I keep them. If not, I remove the tag. I also check [canonical tags](/canonical-tag/) on every page that has a duplicate. A common mistake is pointing the canonical to a 404 or to a URL that redirects. I fix those. Then I check [duplicate content](/duplicate-content/) — not just exact duplicates, but near-duplicates like product pages with only colour variations. I consolidate them with a canonical or a 301.

Performance is next. I open [Core Web Vitals](/core-web-vitals/) in Search Console and look at the URL groups. If LCP hits over 4 seconds, I investigate the server response time and resource loading. I do not chase a perfect Lighthouse score; I look at real-user data. For sites with heavy JavaScript, I run a rendering test to see if Googlebot can see the content. I use the URL Inspection tool and the 'view crawled page' feature. If it is blank, I fix the [JavaScript SEO](/javascript-seo/) issue — usually by making the content available in the initial HTML or by pre-rendering.

Finally, I check structured data. I validate any schema against the visible page content using Google's Rich Results Test. If the data is hidden in a JSON-LD block but the page text does not match, I rewrite it. For multilingual sites, I add [hreflang tags](/hreflang-tags/) and verify them in the same tool. That is the whole list. Seven checks. I run them in order, and I stop when I hit the last one.

I stop when the marginal return on a technical fix is lower than the cost of writing one good piece of content. That threshold is different for every site. For a small blog with 50 pages, once the indexation rate is above 95% and LCP is under 2.5 seconds, I stop. For an e-commerce site with 100,000 product pages, I never really stop — I monitor the crawl budget weekly and automate the checks.

A clear sign to stop is when Search Console's coverage report shows no critical errors and the 'valid' count is stable. I also stop when I have fixed everything that appears in the 'indexed' column and the 'not indexed' column only contains intentional exclusions. If I see a pattern of 'crawled - currently not indexed' for the same page type, I investigate, but I do not hammer the server with more requests. I give Google time to re-crawl after the fix.

I used to keep adding items: image compression, HTTP/2, preload hints, and so on. But I found that those rarely moved the needle on organic traffic. Now I prioritise the checks that affect discovery and indexation first. Performance is important, but only up to the point where it is not causing a crawl delay or a poor user experience. I have seen sites with a perfect Lighthouse score but a broken robots.txt that blocked all pages. The checklist is useless if you ignore the fundamentals.

Another rule: if you cannot fix an issue in a single sprint, flag it as a risk and move on. Do not block the whole project for one server config change. I stop the checklist when I have a clear list of actions that will be completed by the next cycle. I do not try to conquer everything in one pass.

I used to publish a 20-item checklist that covered every possible technical SEO factor. It was a mess. People would ask me where to start, and I had no answer. I now know that a checklist is only useful if it is short enough to complete in one sitting. I cut it down to seven items, and adoption went up.

I also ignored log file analysis for years. I thought it was overkill for most sites. Then I ran a log analysis on a client site and found that Googlebot was spending 80% of its crawl budget on paginated archive pages with thin content. That changed my approach. Now I recommend log analysis for any site with over 10,000 pages. But I still do not include it in the checklist — it is a separate deep-dive.

Another mistake: I recommended noindexing thin content pages without first checking if they had external links. I did this for a client's blog archive pages, and we lost thousands of referral visits. The pages were thin, but they had inbound links from other sites. I should have used a canonical to a more relevant page or left them indexed. Now I always check link profiles before using noindex. I also learned that soft 404s are more dangerous than hard 404s because they waste crawl budget without telling the bot to stop. I missed that in my early checklists.

My biggest regret is treating the checklist as a one-time task. Technical SEO is not a project you finish; it is a routine. I now run a condensed version of this checklist every month, and I track the number of critical issues over time. That is the only way to catch regressions.