Technical SEO checklist: 12 checks from Google's own docs

A technical SEO checklist is a list of checks that confirm search engines can crawl, render, index and understand your site. It is for marketers, founders and developers who want their content to have a fair chance of ranking. If these checks fail, nothing else in SEO works, because a page Google cannot fetch or index cannot rank.

This piece is the practical companion to SEO fundamentals: crawling, indexing and ranking. That article explains how search works. This one is the list you run against a real site.

What does a technical SEO checklist cover?

A technical SEO checklist covers everything between your server and Google's index: access, signals and speed. It does not cover keyword choice or writing quality. Those sit in on-page and content work.

The twelve checks below follow the order Google processes a page: can it reach the URL, may it index it, which version counts, what does the page mean, and is it a good experience on a phone. Every item links to the Google or web.dev page that defines it, so you can check the rule yourself rather than trust a tool's opinion.

Why does technical SEO matter now?

Technical SEO matters more now because the same index feeds both classic results and AI answers. Google says there are no extra requirements for AI features beyond being indexed and eligible for a snippet, which I cover in engine optimisation explained. So a crawl or index problem now costs you citations as well as clicks.

The rules have also moved in the last three years. On 12 March 2024, Interaction to Next Paint (INP) replaced First Input Delay as a Core Web Vital. In August 2023 Google limited FAQ rich results to "well-known, authoritative government and health websites" and then stopped showing HowTo results on desktop as well as mobile. In June 2025 it phased out seven more structured data types, and in November 2025 it said Search Console support for retired types would end from January 2026. A checklist written in 2022 is now partly wrong.

Technical SEO does not make a page win. It makes sure the page is allowed to compete.

How do you run a technical SEO check?

Work through the twelve checks in order, fixing blockers before polish. Use Google Search Console, a crawler and your server logs; most checks need no paid tool.

1. Crawlability: can Googlebot reach the pages?

Check robots.txt does not block pages, CSS or JavaScript you need indexed. Google's robots.txt guide is clear that robots.txt "is not a mechanism for keeping a web page out of Google." It controls crawling only. Also check that real pages return 200, removed pages return 404 or 410, and moved pages use a single 301 redirect, not a chain.

2. Indexability: are the right pages allowed in?

Use noindex for pages you want out of search, and leave them crawlable so Google can see the rule. Then open the Search Console page indexing report and read every "Excluded" reason. A stray noindex left over from a staging site is one of the most common causes of a sudden traffic drop.

3. Canonicals: does one URL represent each page?

Give every page a self-referencing canonical, and point duplicates (tracking parameters, print versions, filter URLs) at the main version. Google's duplicate URL guide calls redirects and rel="canonical" strong signals and sitemap inclusion a weak one. It also warns against using robots.txt or noindex to pick a canonical. Remember that a canonical is a hint: Google can choose differently, and the URL Inspection tool shows which one it picked.

4. Hreflang: are language versions linked both ways?

If you publish in more than one language or region, Google's localised versions guide sets three rules. Each version must list itself and all others. Links must be reciprocal: "If two pages don't both point to each other, the tags will be ignored." Codes use ISO 639-1 for language and an optional ISO 3166-1 region, so hi-IN works but IN alone does not. Add an x-default for visitors who match no version.

5. Structured data: are you marking up what Google still shows?

Mark up only features Google still supports, and only content that is visible on the page. When I checked Google's search gallery on 13 October 2026, it listed 25 features, including Article, Breadcrumb, Product, Review snippet, Recipe, Event, Job posting, Local business, Organization, Video, Discussion forum and Profile page. FAQ and HowTo are no longer there. Course Info, Claim Review, Estimated Salary, Learning Video, Special Announcement, Vehicle Listing and Book Actions were the seven retired in June 2025. Validate with the Rich Results Test, and do not expect markup to lift rankings by itself.

6. Core Web Vitals: is the page fast and stable for real users?

Meet all three "good" thresholds from web.dev, measured at the 75th percentile of real page loads, on mobile and desktop separately:

• Largest Contentful Paint (LCP): 2.5 seconds or less; above 4 seconds is poor.
• Interaction to Next Paint (INP): 200 ms or less; above 500 ms is poor.
• Cumulative Layout Shift (CLS): 0.1 or less; above 0.25 is poor.

Google's page experience guide says Core Web Vitals "are used by our ranking systems" but that "there is no single signal." Fix them for users first. Use the Search Console report for field data, not a single lab score.

7. Mobile-first indexing: does the phone version carry everything?

Google now crawls almost every site with its smartphone crawler; its June 2024 notice said the last desktop-crawled sites would move after 5 July 2024. So the mobile version must have the same main content, headings, structured data, titles, meta descriptions and robots rules as desktop. Do not hide primary content behind a tap that loads it later.

8. JavaScript rendering: is the content in the rendered HTML?

Google crawls, then queues pages for rendering, then indexes. Its JavaScript SEO basics says a page may wait in that queue "for a few seconds, but it can take longer," and that "server-side or pre-rendering is still a great idea." Check three things: links are real <a href> elements, missing pages return a real 404 rather than a soft 404, and you never ship noindex in the original HTML hoping JavaScript will remove it, because Google may skip rendering when it sees one.

9. HTTPS: is every page served securely?

Serve every URL over HTTPS, redirect HTTP to HTTPS once, and fix mixed-content warnings. Google announced HTTPS as a ranking signal in August 2014, calling it "only a very lightweight signal." Its real value is trust and clean canonicals, since HTTP and HTTPS copies of a page otherwise compete.

10. Site architecture and internal links: can every page be reached in a few clicks?

Link every important page from at least one other indexable page, using descriptive anchor text. Group pages into clear hubs (a pillar and its cluster articles), keep the main ones within about three clicks of the home page, and find orphan pages by comparing your crawl with your sitemap.

11. XML sitemaps: do they list only canonical, indexable URLs?

Google's sitemap guide limits a file to 50,000 URLs or 50MB uncompressed, and asks for absolute URLs. It uses lastmod only if it is "consistently and verifiably" accurate, and it "ignores <priority> and <changefreq>." List only 200-status canonical pages and submit the sitemap in Search Console.

12. Log files: what did Googlebot actually fetch?

Server logs show every request Googlebot made, which no crawler tool can. First verify the bot: a reverse DNS lookup should end in googlebot.com, google.com or googleusercontent.com, and a forward lookup should return the same IP. Then look for crawl spent on parameters, redirects and errors. The Search Console Crawl Stats report gives a lighter view by status code, file type and Googlebot type.

When should you do each check?

Do the blockers in the first week and the rest within a month. A workable plan:

• Week one: checks 1 to 3 and 9, because they decide whether pages can be indexed at all.
• Weeks two and three: checks 4, 7, 8, 10 and 11.
• Week four: checks 5, 6 and 12, which need field data and logs to judge properly.
• Every quarter and after every migration: rerun the whole list.

Where does technical SEO go wrong in India?

It goes wrong most often on mobile speed, language versions and JavaScript-heavy builds. Many Indian users browse on mid-range phones and patchy networks, so a page that passes on office Wi-Fi can fail INP and LCP in the field. Check the mobile field data, not the desktop lab score.

Bilingual sites often publish Hindi or regional pages without hreflang, or with one-way tags that Google ignores. And D2C brands built on single-page app frameworks frequently ship product pages whose content only appears after JavaScript runs, with filter URLs that create thousands of duplicates.

Who should own technical SEO?

The SEO or growth lead should own the checklist, and developers should own the fixes. Developers handle redirects, rendering, speed and HTTPS. Content teams own internal links and visible content that structured data describes. Whoever runs the server owns the logs. Small sites on a managed platform can skip deep log analysis and lean on Search Console instead.

My view

My view is that technical SEO is the least glamorous part of marketing and the one that quietly decides results. I led the launch of a D2C app, an expert app and a PWA at VLCC, and the lesson I took is that product and marketing teams must agree on how pages render and how URLs are structured before launch, not after traffic drops.

The trade-off is cost and focus. Every hour a developer spends on schema or log parsing is an hour not spent on the product, and some fixes, such as moving to server-side rendering, are expensive. I would fix the blockers in checks 1 to 3 first, then spend on speed only where the field data shows real users struggling.

Start with the page indexing report

Open Google Search Console today, go to the page indexing report, and read every reason a page is not indexed. For each reason, find the matching check above. That single report will tell you which of the twelve checks to run first.