How to use this checklist
Work from the top. The early sections decide whether the later ones matter. There is no point polishing title tags on pages Google cannot reach.
Group what you find by cause, not by page. A crawler will happily report 400 problems. Usually there are four.
You need very little. Google Search Console, a crawler (Screaming Frog, Sitebulb or Ahrefs), PageSpeed Insights, the Schema Markup Validator and Google’s Rich Results Test, and a browser with JavaScript switched off. The free versions will get most small sites through the whole list.
01
Access and a baseline
Before anything changes, record how things are. If something goes wrong later, this is the only copy of “before” you will have.
- Full access to Search Console on a Domain property, so http, https, www and non-www are all covered. A Domain property is verified with a DNS record, not a meta tag.
- Export 16 months of Search Console performance data. That is all Search Console keeps, and the oldest month drops off every month.
- Build a URL inventory from more than one source: the XML sitemap, Search Console’s page indexing report, twelve months of landing pages from analytics, and every URL that has backlinks. Then crawl the site and compare the lists. Pages that appear in one list but not the others are where problems hide.
- Ask which links the business sends to customers. Search data undervalues pages that people only reach from an email or a PDF.
- Snapshot the important URLs: status code, title, meta description, canonical, H1, robots directives, word count and structured data.
From our logs
On a rebuild we are finishing now, the new build left out an application form the client sends straight to its customers. The page is not indexed and nearly all of its visits come from that link, so in search data it looked unimportant. The client had already flagged it, and it came up again in a review call before launch. That is why the fourth item above is on this list.
02
Can search engines crawl the site?
- Read robots.txt yourself. Check that it blocks nothing search engines need, including CSS and JavaScript files, and that it points to the right sitemap. Check it again after deployments, because a deployment can overwrite it.
- Open Search Console’s crawl stats report, including host status. Server errors and refused requests show up here before they show up in rankings.
- Make sure firewall and bot rules let verified search engines through. Security plugins, server rules and Cloudflare challenges can all stop Googlebot. We cover this in bot and AI crawler control.
- Look at the raw HTML with JavaScript switched off. Content, links and structured data that only appear after scripts run may never be seen by some crawlers. Vercel’s research in 2024 found that major AI crawlers such as GPTBot and ClaudeBot did not run JavaScript.
- Keep staging and preview sites out of the index, and make sure the block does not follow the site to production. Check the WordPress “discourage search engines” setting, noindex tags from your SEO plugin, and any X-Robots-Tag header your host adds.
From our logs
On a UK recruitment site, the problem showed up in Search Console’s crawl stats report. The cause was a ModSecurity rule on the hosting server that was blocking Googlebot and Bingbot. The host whitelisted the rule that was affecting Google. Nothing on the site itself looked wrong.
03
Is the right version of each page indexed?
- Read the page indexing report by reason, not by total. “Crawled, currently not indexed”, “Excluded by noindex tag” and “Duplicate, Google chose different canonical than user” each point somewhere different.
- One version of every URL. http to https, www to non-www (or the reverse), with or without a trailing slash: each variation should reach the final URL in a single permanent redirect.
- A self-referencing canonical on every indexable page, pointing at the production domain.
- Noindex only where you meant it. List every page that carries one and ask why.
- Every page is linked from somewhere. A page that no menu, hub or article links to is an orphan, and orphans get indexed slowly, if at all.
- Check each new page in Search Console when it goes live. URL Inspection tells you whether it can be indexed.
- The XML sitemap lists every indexable, canonical, 200-status URL and nothing else. Its lastmod dates reflect real changes, and it is submitted in Search Console.
- On multilingual sites, hreflang pairs point at each other, and translated pages are actually translated.
From our logs
A client told us new articles were slow to appear in Google, and one landing page would not index at all. The site’s article hub only listed posts from categories ticked in its settings, and the newer categories were not ticked, so new posts were linked from nowhere. The landing page had been left set to private and noindex. We fixed both, made the main article category mandatory, and agreed a simple rule with the client: when a new page goes live, check in Search Console that it can be indexed.
From our logs
On a domain change, the http to https redirect worked on the homepage and nowhere else. Search Console’s Change of Address tool would not accept the move until it was fixed. Test redirects on deep URLs, not only the homepage.
04
Status codes and redirects
- Crawl for 4xx and 5xx errors, then look for the pattern behind the count.
- Every redirect is one hop, permanent (301 or 308), and lands on the closest matching page. No chains, no loops, and no mass redirects to the homepage. Google says redirecting many old URLs to one irrelevant page, such as the homepage, may be treated as a soft 404.
- Old URLs that are still in Google’s index resolve properly. Run a site: search and click through the old ones.
- Keep a 404 log running (the Redirection plugin does this on WordPress) and read it every month.
From our logs
An Ahrefs crawl of 921 URLs flagged 425 pages returning 4XX errors. Every one of them traced back to a single phone number link that had been formatted wrongly. One cause, one fix.
Relaunching or changing domains? Redirects get a page of their own: website migration SEO.
05
Page structure and content
- One H1 per page, and it describes the page.
- Titles are unique and short enough not to be cut off, roughly 50 to 60 characters, with the brand at the end.
- Every indexable page has a meta description written for it.
- On template pages, the page-specific content outweighs the template. Count the words that are unique to the page and compare them with the header and footer.
- Pages built from one template agree with each other. Timelines, requirements and claims should match everywhere they appear.
- Dates are honest. If a page says it has been updated, its modified date should say so too.
- Important pages are linked from body copy, with anchor text that says what the page is.
- Authors are real people. Check the author name on posts and in the structured data. Sometimes it is the admin account.
- Before deleting content, look at its data. Pull 16 months of Search Console impressions for every page on the list.
From our logs
We checked every page of a 93-page site for H1 tags. 28 pages had more than one: 67 H1s between them, of which only 27 were correct. A careers page had six. Another page had an empty one. On 20 of the 28 pages, the extra H1 was the same thing: a related-articles block coded as an H1 in a shared template. One change to that template covers 20 pages. The other eight need a person. On the new build, no page has more than one H1.
From our logs
On a set of 17 pages built from one template, the text unique to each page came to between 60 and 130 words. The header and footer alone came to about 204. Two pages quoted a timeline of four to seven weeks, and another said four to eight. Sixteen of the 17 had a modified date identical to the published date, and four were dated 2024 while promising a 2026 update. Most of this only shows up when you compare the pages side by side, which is where AI earns its place. We explain how in how we test websites with AI.
From our logs
On one blog, before recommending any post for deletion, we checked 16 months of Search Console impressions for each one. Only posts with fewer than 1,000 impressions in that window went on the delete list.
06
Structured data and social tags
- Structured data parses without errors in the Schema Markup Validator, and the types Google supports pass the Rich Results Test.
- The markup matches the visible page: breadcrumb trail, names, dates and FAQ text.
- The organization is described once and referenced by @id everywhere else. No page should carry two competing descriptions of itself. That happens when an SEO plugin and custom code both output markup.
- Open Graph tags are right on every page: og:type set to article for articles and website for the rest, a real og:image, and og:url matching the canonical.
FAQ rich results stopped appearing in Google on May 7, 2026. FAQ markup can stay on pages with a visible FAQ, but it no longer earns extra space in search results, so do not audit for it.
From our logs
A company name was misspelled in one page’s H1. It was also misspelled in the page title, the Open Graph title and the JSON-LD. One typo, four places, and only one of them visible on the page.
More on this in schema markup.
07
Speed and Core Web Vitals
- Read field data first: the Core Web Vitals report in Search Console and the field section of PageSpeed Insights. These come from real visitors, and they are what Google uses. Lab scores come second.
- Find the LCP element on each key template. Check it is not lazy-loaded, is sized for the space it fills, and is fetched with high priority.
- Check server response time under real traffic, not only in a quiet test. Bots and background scans slow a server down for everyone.
- Caching skips pages that must stay dynamic: cart, checkout, account pages and forms. Cached forms can fail with a nonce error.
From our logs
A client site scored 99 on desktop and 98 on mobile in PageSpeed Insights’ lab test while failing Core Web Vitals for real visitors. Only LCP was failing, and our diagnosis pointed to server response time under load, which a single lab run does not see.
The full method is on our Core Web Vitals page.
08
The checks most audits skip
These test the business, not the page. No crawler will flag them.
- Submit every form and confirm the email arrived and the lead reached the CRM. A thank-you page on its own proves nothing. During an audit, agree a test method with the client first, so test leads do not end up in their sales pipeline.
- Search the site for things you know are there, and write down how many results you expect. If the number moves sharply, search or filtering has broken, even though the page still loads. On stores this matters most; see WooCommerce SEO.
- Check that analytics records the actions that matter, and that consent mode is set up where it is required.
- Read the mail log, not the inbox. Failed sends show up there first.
09
After the audit
An audit is a snapshot. These checks keep it true.
- Every month: the 404 log, Search Console crawl stats, failed emails, and that month’s support emails turned into test cases.
- After every launch: our own bar is a site health score of at least 95 in Ahrefs, and no URL in Google’s index returning a 404.
- Every quarter: the checks too slow to run monthly, such as duplicate products and categories on a store, or confirming that people who should not see something still cannot.
On our maintenance retainers, these run on a written schedule.
Frequently asked questions
How often should a website be audited?+
In full, before and after any launch or redesign. In between, a short monthly check of the 404 log, crawl stats and failed emails catches most problems while they are still small. Online stores benefit from a weekly check as well.
Do I need to fix everything a crawler reports?+
No. Group the findings by cause and fix the causes that touch pages you care about. Some warnings need no work at all. On one site, a “Google chose different canonical than user” warning traced back to a redirect between two blog posts, and the client’s SEO consultant confirmed it was reporting lag.
Which tools do I need for an SEO audit?+
Google Search Console, a crawler, PageSpeed Insights, the Schema Markup Validator and a browser. Paid crawlers save time on large sites, but free versions will get most small sites through this whole list.
What is the difference between a technical SEO audit and a content audit?+
A technical audit asks whether search engines can reach, read and understand your pages. A content audit asks whether those pages deserve to rank. This checklist is mostly technical, plus the content problems that templates create at scale.
Can AI run an SEO audit?+
AI is good at finding the twentieth instance of a problem a person has already spotted. It is poor at deciding what matters, and it can be confidently wrong: an AI draft of one client’s structured data gave them another organization’s founding year. We use it to draft and to repeat checks at scale, and a person checks every finding against the source.
Can you audit a site you did not build?+
Yes. Almost nothing on this list depends on who built the site.
Sources
- Google Search Central, Introduction to robots.txt
- Google Search Central, Site moves with URL changes
- Google Search Central, FAQPage structured data
- Vercel, The rise of the AI crawler (December 2024)