October 08, 2026
A checklist for an SEO audit has to answer four questions about a website, in order: can Google find and index the pages, do the pages say plainly what they are about, can Google read them as data, and are they fast and sound on a phone. The 31 checks below do that, grouped the way we work through them, each with the free tool that gives the answer: Google Search Console, PageSpeed Insights, the Rich Results test, and a crawler such as Screaming Frog, whose free tier handles up to 500 URLs.
This is the list we ran on our own site after rebuilding it this year. It found 17 of 28 pages sitting at "Discovered, currently not indexed" the day after launch, 17 titles over 60 characters, a sitemap with no images in it, a canonical tag that copied whatever URL was requested, and 141 KB of JavaScript nobody was using. Site health in the crawl tool went from 61 to 84 to 95 as the list was worked through. Those numbers appear against the checks that found them.
Technical SEO is everything that lets Google find, read and trust a page before the words on it matter. A shop with the best stock in town sells nothing if the door is locked, the sign is blank and the lights are off. Crawling is the door: can Google reach the page. Indexing is the sign: has Google decided the page is worth keeping. Speed and structured data are the lights: can Google and a person on a phone see what is there without effort.
It sits apart from content SEO (writing the page for the question someone typed) and off page SEO (other sites mentioning yours). An audit checks the technical side first because a content problem on an unindexed page is not the problem yet.
The tools for a website audit, all free:
That set is enough for any site under 500 pages, which is nearly every business site in India.
1. Property verified and a sitemap submitted. Why: every other report depends on it, and an unsubmitted sitemap is the most common reason a new site is invisible. Tool: Search Console, Sitemaps.
2. Page indexing report read line by line. Why: "Discovered, currently not indexed" and "Crawled, currently not indexed" tell you Google has seen a page and declined it. Ours showed 17 of 28 the day after launch; the fix was a resubmitted sitemap, footer links to the new pages and IndexNow. Tool: Search Console, Pages.
3. robots.txt does not block CSS, JavaScript or a folder the site needs. Why: a blocked stylesheet makes Google see a broken page and index it as one. Tool: open the file in a browser; Search Console's robots.txt report.
4. No stray noindex tags. Why: a noindex left over from staging quietly removes a page for months. Tool: crawler, Directives tab.
5. The sitemap lists only canonical, indexable pages that return 200, and it lists images. Why: Google trusts a clean sitemap and ignores a messy one. Our old one listed no images; the new one lists 131. Tool: crawler in list mode against the sitemap URL.
6. URL inspection on the five pages that matter most. Why: it shows the exact indexed version, the canonical Google chose and the last crawl date. Tool: Search Console, URL inspection.
7. Manual actions and security issues reports are empty. Why: nothing else on this list matters if either shows a problem. Tool: Search Console.
If a page is missing from Google altogether, our diagnostic on why a website is not showing on Google (article 03) goes through the causes in order.
8. Every page has a unique title under 60 characters with the keyword in its first half. Why: the title is the blue link, and Google rewrites long or duplicate ones. Our crawl found 17 over the limit. Tool: crawler, Page Titles tab.
9. Every page has a meta description of 120 to 155 characters written for a person. Why: it is the grey text under the link, and a missing one is replaced by whatever Google picks. Tool: crawler, Meta Description tab.
10. One H1 per page, and it states the page's question or subject. Why: two H1s or none confuses what the page is about. Tool: crawler, H1 tab.
11. H2s in a sensible order with no heading levels skipped for styling. Why: headings are the outline Google reads; a skipped level is a missing chapter. Tool: crawler, H2 tab, or the browser's outline.
12. No two pages built for the same keyword. Why: they compete and Google picks one, usually the wrong one. Tool: crawler export sorted by title; Search Console, Performance, filtered by query.
13. No thin pages: under about 300 words with no other purpose. Why: they drag down the site's overall quality signal. Merge them, expand them or noindex them. Tool: crawler, Word Count column.
14. An Organisation or LocalBusiness node on the home page with name, address, phone and sameAs links, in one @graph rather than several competing blocks. Why: it is how Google confirms the business behind the site. Tool: Rich Results test.
15. Breadcrumb, FAQ, Article and Product markup wherever the page has that content, with zero errors. Why: errors make the whole block ineligible; warnings do not. Tool: Rich Results test, Schema Markup Validator.
16. The structured data matches what is visible on the page. Why: markup describing content that is not there is treated as spam. Tool: read the page beside the test result.
Our piece on schema markup for a local business website (article 21) has the exact fields and a template.
17. Field data first. Why: PageSpeed Insights shows what real Chrome users experienced over 28 days, and that is what Google ranks on. Our mobile lab run reported LCP 5.5 s and CLS 0.251 while a throttled real device measured CLS 0.006, so the lab number needed checking against the field before anyone panicked. Tool: PageSpeed Insights, top panel; Search Console, Core Web Vitals.
18. The LCP element identified and its image sized, preloaded and served in WebP. Why: the largest thing above the fold is usually one image, and one image is easy to fix. Tool: PageSpeed Insights, Diagnostics.
19. Unused JavaScript measured and removed. Why: every kilobyte is parsed on a phone before the page responds; ours had 141 KB doing nothing. Tool: PageSpeed Insights, "Reduce unused JavaScript".
20. Render blocking CSS and JavaScript checked, and any change tested for layout shift. Why: moving scripts around can fix one metric and break another, which is why the field data matters. Tool: PageSpeed Insights, "Eliminate render blocking resources".
21. Compression and caching headers on. Why: gzip or brotli and a long cache life for static files are free speed. Tool: browser developer tools, Network tab, response headers.
22. A run on a real phone over a throttled connection. Why: the lab is a fast machine in a data centre; your customers are on a 4G connection in Rajkot. Tool: Chrome developer tools with network throttling, or a low end Android phone.
For each cause of slowness and its fix, see how to increase website loading speed (article 07). For reading the report itself, see Core Web Vitals assessment failed (article 27).
23. Every image is WebP with size variants and width and height attributes. Why: the browser reserves the space, which prevents layout shift, and the phone downloads the size it needs. Tool: crawler, Images tab; PageSpeed Insights, "Properly size images".
24. Every image has a descriptive filename and an alt text that says what is in it. Why: "product-1.jpg" ranks for nothing and reads nothing to a screen reader; "n-type-topcon-solar-module-front.webp" does both jobs, and a solar module manufacturer we work with names its product images that way. Tool: crawler, Images tab, filter missing alt text.
25. Images appear in the sitemap. Why: Google finds gallery and product images faster from the sitemap than by crawling. Tool: open the sitemap; crawler in list mode.
26. http to https, and www to non www (or the reverse), each resolve with one 301 and no chain. Why: a chain of three redirects wastes crawl budget and speed on every visit. Tool: crawler, Redirect Chains report; browser Network tab.
27. Every page has a canonical tag pointing at its own clean URL, fixed in the code rather than copied from the request. Why: a canonical that echoes the requested URL turns every ?utm link into a duplicate page, which is exactly what our case study pages did until we fixed it. Tool: crawler, Canonicals tab.
28. No broken internal links and no 404s that used to be real pages. Why: each is a dead end for a visitor and for Google, and old URLs with links pointing at them should redirect. Tool: crawler, Response Codes; Search Console, "Not found (404)".
29. Every important page reachable within three clicks from the home page and linked from the navigation or the footer. Why: pages that only the sitemap knows about are the ones Google leaves at "discovered"; adding footer links was part of our own fix. Tool: crawler, Crawl Depth column.
The security checks that belong beside these, headers, backups and the admin login, are in our website security checklist (article 29).
Yes, because an audit without measurement cannot tell you whether the fixes worked.
30. Analytics installed once on every page, with the actions that matter recorded as conversions: form submissions, WhatsApp button taps, phone number taps. Why: traffic is not the goal; enquiries are, and a duplicate tag doubles every number. Tool: Google Tag Assistant; the Realtime report while you click your own buttons.
31. Search Console and Analytics linked, and a monthly note that compares queries and pages, not just totals. Why: totals hide the story. Our own 90 days showed 66 clicks, 50 of them for the studio's name, and a mobile click rate of 2.3 percent against 8.4 on desktop; the total alone said nothing was wrong. Tool: Search Console, Performance, compared by device and by query.
That comparison opens every monthly report in our SEO service: the audit sets the baseline, the report shows what moved.
For a site under 100 pages, the 31 checks take a day with the tools above, and a second day to write up what to fix in what order. Larger sites take longer because of the crawl and the number of templates to read.
It covers indexing, Core Web Vitals from the field and search performance, which is half the list. It does not show titles, headings, canonicals or broken links across the site; that needs a crawler.
Fully, once a year or after any rebuild or platform change. The indexing and Core Web Vitals reports in Search Console should be read monthly, because a problem there is cheap to fix early.
Many providers include it in the first month of a retainer, roughly 8,000 to 25,000 rupees a month for a small business. The range depends on page count, how many templates the site uses and whether the provider fixes what it finds or only reports it.
Sign in with Google to join the conversation. We use it for your display name and nothing else, and your email address is never shown.
No comments yet. Sign in above to write the first one.