A technical SEO checklist answers one question for every page you care about: can Google reach it, read it and add it to its index? If the answer is no, the page can’t rank, no matter how well it’s written. The 12 checks below cover crawler access, indexing, status codes, duplicate URLs, redirects, sitemaps, mobile pages, speed, links, JavaScript and structured data. Each one comes with the free tool to check it and what a pass looks like, so you can run it yourself or hold whoever manages your site to it.
In short
- Google’s bar for indexing is short: Googlebot isn’t blocked, the page returns a 200 status code, and it has indexable content.
- robots.txt controls crawling, not indexing. To keep a page out of Google, use noindex or a password, and leave that page crawlable so Google can see the tag.
- Pick one address for every page (HTTPS, with or without www) and point redirects, canonical tags and your sitemap at it.
- Google indexes the mobile version of your site, so phones need the same content, headings and structured data as desktop.
- Search Console’s URL Inspection tool and its reports catch most of this list, and they’re free.
What a technical SEO checklist covers
Technical SEO is the work that lets search engines reach, read and index your pages. On-page SEO and content both depend on it.
Google’s own technical requirements for Search fit in three lines. A page is eligible to be indexed when Googlebot isn’t blocked, the page works (Google receives an HTTP 200 status code) and the page has indexable content. The page also says it “costs nothing to get your page in search results, no matter what anyone tries to tell you.”
Eligible isn’t the same as indexed, and indexed isn’t the same as ranking well. But a page that fails any of those basics is out before quality or links come into it.
Tools you need before you start
You don’t need paid software for a small site:
- Google Search Console. URL Inspection shows whether a page is indexed, the status code Google got and which canonical it chose. The Page indexing, Sitemaps and Core Web Vitals reports cover the whole site.
- The Rich Results Test. Google’s free structured data validator.
- View Page Source in your browser (not Inspect). That’s the raw HTML a crawler receives before scripts run.
- A site crawler, optionally. It lists every URL’s status code, redirect and canonical in one sheet, which saves hours on bigger sites.
The checklist at a glance
| # | Check | What a pass looks like |
|---|---|---|
| 1 | robots.txt | No Disallow rule covers a page you want found |
| 2 | Key pages indexed | URL Inspection shows every important page as indexed |
| 3 | noindex | Only on pages you mean to hide |
| 4 | Status codes | 200 for live pages, 404 or 410 for removed ones, no 5xx |
| 5 | One URL per page | http, https, www and non-www all land on one HTTPS address |
| 6 | Redirects | 301 or 308, one hop to the final page |
| 7 | XML sitemap | Only canonical, indexable pages, read without errors |
| 8 | Mobile | Same content, headings and structured data as desktop |
| 9 | Core Web Vitals | LCP within 2.5 seconds, INP under 200 ms, CLS under 0.1 |
| 10 | Links | Real <a href> links to every important page |
| 11 | Content in HTML | Main text appears in the page source |
| 12 | Structured data | No errors, and it only describes what’s on the page |
Work in order. Checks 1 to 4 decide whether pages can be indexed at all.
Crawling and indexing: checks 1 to 4
These come first because they hide every other problem. If Googlebot can’t fetch a page, it can’t see the content, the noindex tag or the canonical.
1. robots.txt isn’t blocking pages you want found
Open yoursite.com/robots.txt and read every Disallow line. Google’s introduction to robots.txt says the file is used mainly to keep crawlers from overloading your site, and that “it is not a mechanism for keeping a web page out of Google.” A blocked page can still show up in results with no description, and Google says a disallowed URL can still be indexed if other sites link to it.
So robots.txt is the wrong tool in both directions: it won’t reliably hide a page, and one careless rule can stop Google from reading pages you want found. The classic case is a leftover staging rule that blocks everything:
User-agent: *
Disallow: /Also look for rules blocking your CSS or JavaScript folders. Google says that if blocking those files makes a page harder for its crawler to understand, don’t block them.
2. Your key pages are indexed
Run your homepage, service pages, location pages and best posts through URL Inspection. It tells you whether each page is in Google’s index and, if it isn’t, the reason Google reports. On a larger site, Google’s technical requirements page also suggests the Page Indexing and Crawl Stats reports for finding pages Google can’t access.
Don’t panic over every unindexed URL. Duplicate addresses, redirected URLs and pages you’ve noindexed on purpose are supposed to stay out, and passing Google’s three basics only makes a page eligible. What matters is that the pages you’d want a customer to land on are in. If one of them isn’t, checks 1, 3 and 4 usually explain why.
3. noindex is only on pages you mean to hide
noindex is the switch that actually removes a page from Google. Google’s noindex documentation says that once Googlebot crawls the page and sees the rule, Google drops it “entirely from Google Search results, regardless of whether other sites link to it.” The rule can sit in the page’s HTML head:
<meta name="robots" content="noindex">It can also be sent as an X-Robots-Tag HTTP header, which never shows in the page source. Google says the two methods have the same effect. That’s why URL Inspection is the better test: the same guide recommends it for confirming that Googlebot can actually see your noindex rule.
Two mistakes cause most noindex trouble. One is a site launched with a staging setting still on, quietly adding noindex to every page. The other is pairing noindex with a robots.txt block. Google has to crawl a page to see the tag, and its noindex guide warns that a robots.txt block can stop its crawlers from seeing it. Google also doesn’t support noindex inside robots.txt. To keep a page out of search, use noindex and leave it crawlable.
4. Every page returns the right status code
Live pages should return 200, removed pages 404 or 410, and nothing a 5xx server error. Google’s guide to HTTP status codes says Google doesn’t index URLs that return a 4xx code and removes already indexed ones that start returning one. Server errors make Google’s crawlers slow down for a while, and indexed URLs that keep failing are eventually dropped.
Watch for the quiet version too. A page that returns 200 but shows an error message or an empty page is reported in Search Console as a soft 404. Fix the page or let it return a real 404. Repeated 5xx errors usually point to hosting limits or a plugin conflict, so take them to your host quickly.
Duplicates, redirects and sitemaps: checks 5 to 7
Most sites answer at several addresses for the same page. Pick one per page and make every signal point at it.
5. Each page has one address, on HTTPS
Type four versions of your homepage into a browser: http and https, each with and without www. All four should end up at the same HTTPS address. Google’s canonical URL guide ranks the ways to tell it which version you prefer: redirects and rel="canonical" tags are strong signals, sitemap inclusion is a weak one, and they work better together. Google also prefers HTTPS pages as canonical unless something conflicts, such as an invalid SSL certificate, insecure page resources (images aside), or an HTTPS page that redirects through HTTP.
From the same guide:
- Give each page a self-referencing canonical tag. Many site builders add one automatically, so confirm it points to the right address.
- Don’t send mixed signals, like one URL in your sitemap and another in the canonical tag.
- Don’t use robots.txt or noindex for duplicates. Google calls
rel="canonical"the preferred fix. - None of these are required. Without a stated preference, Google picks the version it thinks is best, and URL Inspection shows which one.
6. Redirects are permanent and go straight to the final page
When a page moves for good, use a 301 or 308. Google’s status code guide says it treats a 301 as a strong signal that the redirect target should be processed and a 302 as a weak one, with 308 handled like a 301 and 307 like a 302. Save temporary redirects for moves that really are temporary.
The same guide says Google’s crawlers follow up to 10 redirect hops by default. That’s a ceiling, not a target. Chains pile up quietly after a few redesigns (http to https, then to www, then to a new page name), and each hop slows visitors down. Point every old URL straight at its final page. After a redesign, list your old URLs, map each to its closest new page and test them.
7. Your XML sitemap lists only pages you want indexed
A sitemap is a list of the URLs you want search engines to know about. Google’s sitemap documentation is specific about how it reads one:
- One sitemap holds up to 50,000 URLs or 50MB uncompressed. Larger sites split it.
- Use full, absolute URLs.
- Google ignores the priority and changefreq values, and uses lastmod only when it’s consistently and verifiably accurate.
- Submitting a sitemap is “merely a hint.” It doesn’t guarantee Google will download it or crawl what’s in it.
- You can submit it in Search Console’s Sitemaps report, list it in robots.txt, or both.
The robots.txt line looks like this:
Sitemap: https://www.example.com/sitemap.xmlMost platforms generate a sitemap for you, so your job is checking what’s in it. A clean one holds only canonical pages that return 200 and are allowed in the index: no redirects, 404s, noindexed pages or tracking parameter duplicates. Then confirm in the Sitemaps report that Google could read it.
Mobile and speed: checks 8 and 9
Google indexes the phone version of your site and measures how pages load and respond.
8. The mobile version has everything the desktop version has
Google’s mobile-first indexing guide says it uses the mobile version of a site’s content, crawled with its smartphone agent, for indexing and ranking. It recommends responsive design (the same HTML at the same URL on every device) as the easiest setup to maintain.
If your mobile pages differ from desktop, that guide asks for:
- The same content. Tabs and accordions are fine if the content is equivalent.
- The same headings and structured data.
- The same robots meta tags. A different noindex or nofollow on mobile may stop Google from crawling and indexing the page.
- No content that waits for a tap. Google won’t load content that needs a swipe, click or typing to appear.
The quick test: open each key page on your phone beside the desktop version and look for missing service details, reviews, FAQs or photos.
9. Core Web Vitals pass
Core Web Vitals are Google’s three measurements of real visitors’ experience. Google’s Core Web Vitals page sets these targets:
| Metric | What it measures | Good result |
|---|---|---|
| Largest Contentful Paint (LCP) | Loading | Within the first 2.5 seconds of the page starting to load |
| Interaction to Next Paint (INP) | Responsiveness to taps and clicks | Less than 200 milliseconds |
| Cumulative Layout Shift (CLS) | Visual stability | Less than 0.1 |
Keep them in proportion. The same page says Google highly recommends good Core Web Vitals “for success with Search,” and that they, along with other page experience aspects, line up with what its core ranking systems seek to reward. That’s a good reason to fix slow pages, not a reason to chase a perfect score while your content waits. Open the Core Web Vitals report in Search Console and fix pages marked Poor first. Usual suspects: oversized images, too many plugins and third-party scripts, slow hosting, and embeds that load without reserved space and push the page around.
Links, JavaScript and structured data: checks 10 to 12
These make sure Google can follow your site’s structure and read each page.
10. Important pages are reachable through real links
Google’s JavaScript SEO basics puts it plainly: Google can only discover your links if they are <a> HTML elements with an href attribute. Menus built from buttons or click handlers can look fine and still hide pages from crawlers.
Every important page should be reachable from your menu or from links on other pages. Pages nothing links to are hard for search engines to find. Use anchor text that says what the reader gets, like “drain cleaning prices” rather than “learn more.”
11. Your key content is in the HTML
The same Google guide explains that JavaScript pages go through three phases (crawling, rendering and indexing) and that a page can wait in the rendering queue for a few seconds or longer. Google recommends server-side rendering or pre-rendering anyway, because it makes a site faster for users and crawlers, and “not all bots can run JavaScript.”
That last point reaches well beyond Google. Our guide on how to optimize for AI search covers what’s known about AI crawlers and JavaScript, along with the robots.txt rules for those crawlers. The test takes a minute: open View Page Source on a key page and search for a sentence from your main content. If it isn’t there, ask your developer about rendering that content on the server.
12. Structured data is valid and matches the page
Structured data is code (usually JSON-LD) that labels what a page is about, such as your business details or FAQs. Google’s general structured data guidelines set the rules: include every property your rich result type requires, don’t mark up content that isn’t visible to readers, and test with the Rich Results Test or URL Inspection, which Google says catch most technical errors.
Those guidelines also say a structured data manual action costs a page its eligibility for rich results but “doesn’t affect how the page ranks in Google web search.” Treat markup as a way to describe pages accurately and qualify for richer listings, not as a ranking lever. For a local business, the markup that usually matters most is LocalBusiness, which our local SEO guide for small businesses walks through.
How often to run this checklist
Run the full checklist at least once a year and after any redesign, platform switch, domain change or major plugin update. Check Search Console monthly for new indexing errors, sitemap problems or Core Web Vitals slipping into Poor. When several problems turn up at once, fix them in list order: a noindex tag on your services page costs far more than a slow image on your About page.
How we handle technical SEO
On-site technical SEO is part of our monthly plan, alongside keeping your site in line with Google’s algorithm updates. We work through checks like these on your website, fix what we find, and list each task in your monthly report. You keep ownership and full control of your site and accounts and give us access to do the work.
Frequently asked questions
What is a technical SEO checklist?
It’s a list of checks that confirm search engines can crawl, render and index your website. A good one covers robots.txt, noindex tags, status codes, duplicate URLs and canonicals, redirects, XML sitemaps, mobile content, Core Web Vitals, crawlable links, JavaScript and structured data.
How often should I run a technical SEO audit?
Run a full pass at least once a year and after any redesign, platform switch, domain change or major plugin update. In between, check Search Console monthly for new indexing errors, sitemap problems and Core Web Vitals changes.
Does robots.txt keep a page out of Google?
No. Google says robots.txt is not a mechanism for keeping a page out of Google, and a blocked URL can still be indexed if other sites link to it. Use a noindex rule, password protection or removal instead, and don’t block that page in robots.txt, because Google has to crawl the page to see the noindex.
Are Core Web Vitals a ranking factor?
Google highly recommends good Core Web Vitals for success with Search and says they, along with other page experience aspects, align with what its core ranking systems seek to reward. Treat them as one part of a healthy site: fix pages marked Poor first rather than chasing a perfect score.
Can I do technical SEO myself?
For a small site, much of it, yes. Search Console, the Rich Results Test and your browser’s page source cover most of this checklist for free. Redirect mapping, JavaScript rendering and server errors are where a developer or SEO specialist usually earns their fee.
Want technical SEO, content and your Google Business Profile handled every month? See what our $950 a month plan includes, or send us a question first.