A technical SEO checklist should answer one question in order: can Google crawl your pages, index them, render them, and show them well? Check crawling and indexing first, because nothing else matters if your pages aren’t in Google. Speed and structured data come after, and most small sites can do the whole list with Google Search Console and a free crawler.
Most checklists you’ll find list 50 to 100 items with equal weight. On a 30-page business site, half of them don’t apply and the other half are in the wrong order. The list below is grouped into five stages, ordered by how much damage a problem at that stage does, and every item says where to check it. Google’s rules were checked against its own Search Central documentation in October 2026.
Before you start: two free tools
You need two things for almost every item:
- Google Search Console. If the site isn’t verified yet, do that first. The Page indexing report, URL Inspection and Core Web Vitals report do most of the checking for you.
- A crawler. Screaming Frog’s free version crawls up to 500 URLs, which covers most small business sites. It finds broken links, redirect chains, missing titles and stray noindex tags in a few minutes.
Stage 1: crawling
If Googlebot can’t reach a page, nothing else on this list matters for that page.
- Check robots.txt. Open yoursite.com/robots.txt and read every
Disallowline. Look for a leftoverDisallow: /from a staging site, which blocks everything. Google says robots.txt is “used primarily to manage crawler traffic” and is not a way to keep a page out of Google. A blocked page can still be indexed if other sites link to it. - Submit an XML sitemap. Add it under Sitemaps in Search Console. One sitemap can hold 50,000 URLs or 50MB, which no small site will hit. List only the pages you want in Google: no redirects, no noindexed pages, no 404s.
- Don’t bother with priority and changefreq. Google’s sitemap documentation says it ignores both. It does use
lastmod, but only if the date is “consistently and verifiably” accurate, so don’t let your CMS stamp today’s date on every page. - Use real links. Google only follows links that are
<a>elements with anhref. Menus built from buttons with JavaScript click handlers can hide whole sections of a site. - Find orphan pages. Compare the URLs in your sitemap with the URLs your crawler found by following links. A page in the sitemap that no other page links to will struggle, even if it’s indexed.
Step 1 is the one that matters most. One wrong line in robots.txt can remove a site from search faster than any other mistake on this list, and it’s usually left behind by a developer during a redesign.
Stage 2: indexing
Crawled doesn’t mean indexed. Open Indexing, then Pages in Search Console and read the “Why pages aren’t indexed” table. Each reason needs a different response.
| Reason in Search Console | What it usually means | What to do |
|---|---|---|
| Not found (404) | A deleted or mistyped URL | Fix only if you link to it or it had traffic |
| URL marked ‘noindex’ | You told Google to skip it | Check it’s on purpose |
| URL blocked by robots.txt | Robots.txt stops the crawl | Check it’s on purpose |
| Duplicate without user-selected canonical | Google found copies and picked one itself | Add a canonical tag |
| Duplicate, Google chose different canonical than user | Google ignored your canonical | Check the copies really differ |
| Crawled - currently not indexed | Google read it and passed | Improve or merge the page |
| Discovered - currently not indexed | Google knows it but hasn’t crawled it yet | Add internal links to it |
| Page with redirect | The URL redirects | Nothing, unless it’s in your sitemap |
The names in the table are the ones Google uses in the Page indexing report. Not every entry is a problem. A noindexed thank-you page and a redirected old URL are doing exactly what they should. The ones to act on are pages you want in Google that sit under any of these reasons.
For 404s in particular, our guide on how to fix 404 errors in Google Search Console covers which to ignore and which to redirect.
Canonical tags
A canonical tag tells Google which copy of a page is the main one. Google calls rel="canonical" “a strong signal”, not an order, and lists the mistakes to avoid:
- Don’t use robots.txt or noindex to pick a canonical. Robots.txt can still leave the URL indexed, and noindex removes the page entirely.
- Use absolute URLs (
https://example.com/page/), not relative paths. - Don’t send mixed signals, such as a sitemap listing one URL while the canonical tag points to another.
Every indexable page should have a canonical pointing to itself, unless it’s a deliberate copy.
Sitewide duplicates
Pick one version of the domain and redirect the rest to it: http to https, and www to non-www (or the reverse). Type all four versions into a browser and check each lands on the same address in one hop. A redirect is the strongest canonical signal Google lists, stronger than the tag.
Stage 3: rendering
Google crawls the HTML first, then renders the page in a headless Chromium browser and runs the JavaScript. Google is direct about the risk: “If the content isn’t visible in the rendered HTML, Google won’t be able to index it.”
To check, paste a URL into URL Inspection in Search Console, select Test live URL, then View tested page. Search the HTML tab for a sentence from the middle of your page. If it’s missing, Google isn’t seeing it.
Three rendering problems turn up most:
- Content loaded after a click. Tabs and accordions are fine if the text is in the HTML. They fail when the text only loads from the server after a click.
- Blocked resources. If robots.txt blocks your JavaScript or CSS files, Google can’t render the page properly.
- Noindex added or removed by JavaScript. Google may skip rendering a page that has noindex in the original HTML, so a script that removes it later may never run.
Most WordPress, Squarespace, Shopify and Wix sites render on the server and pass this stage easily. It matters most for sites built as JavaScript apps (React, Vue, Angular) without server-side rendering.
Stage 4: speed and Core Web Vitals
Google measures three Core Web Vitals, and gives a target for each:
These are measured on real visitors, at the 75th percentile of page loads, split by mobile and desktop. So a page passes when three out of four visits meet the target, and your fast office laptop doesn’t count for much.
Check the Core Web Vitals report in Search Console first. It groups URLs that share a problem, so you fix a template once instead of page by page. If the report says there isn’t enough data, which is common for small sites, use PageSpeed Insights on your top pages instead.
The usual fixes, in order of payoff:
- Resize and compress images. A 4MB photo straight from a phone is the most common cause of a slow LCP. Export at the size it displays and use WebP.
- Set image dimensions. Width and height attributes on images and embeds stop the page jumping as they load, which fixes most CLS problems.
- Cut third-party scripts. Chat widgets, heatmaps, old tracking pixels and social embeds are the usual cause of a poor INP. Remove the ones nobody looks at.
Google says good Core Web Vitals align with “what our core ranking systems seek to reward”. It’s one signal among many, so don’t spend a month shaving 0.2 seconds off a page that already passes.
Stage 5: the extras
These matter, but rarely as much as the first four stages.
- HTTPS everywhere. Every page on
https, with no mixed content warnings in the browser. - Redirect chains. A redirect to a redirect to a page wastes crawls and slows visitors. Your crawler lists chains. Point each old URL straight at the final one.
- Broken internal links. Fix links on your own pages that point to 404s. This is the one kind of 404 that’s always worth fixing.
- Mobile layout. Google indexes the mobile version of your pages, so check that the mobile page has the same content as desktop, not a cut-down version.
- Structured data. Add the types that match your content, such as LocalBusiness for a local business, and test them with Google’s Rich Results Test. Our free local business schema generator writes the markup for you. Skip FAQ markup if you’re adding it for the dropdowns in search results: Google stopped showing them in May 2026, as our guide to FAQ schema markup explains.
- Titles and meta descriptions. Every indexable page needs a unique title. Your crawler lists missing and duplicate ones. Use the SERP preview tool to check how they’ll display.
How to run this as an audit
If you’re auditing a site for the first time, or for a client, work in this order and stop to fix anything serious before moving on:
- Read robots.txt and confirm the sitemap is submitted and clean.
- Open the Page indexing report and list every page you want indexed that isn’t.
- Run a full crawl and export redirects, 404s, missing titles and noindexed pages.
- Test five important pages with URL Inspection, including the rendered HTML.
- Check the Core Web Vitals report, or PageSpeed Insights on your top pages.
- Check structured data, HTTPS and mobile layout.
Step 2 is where most audits find their biggest win. A service page sitting under “Crawled - currently not indexed” earns nothing, and you can only see that in Search Console.
Write up what you find in order of impact, not in the order you checked it. If you report on SEO each month, the indexing line belongs in the site health section of our monthly SEO reporting template.
FAQ
What is included in a technical SEO checklist?
Crawling (robots.txt, sitemaps, links), indexing (the Page indexing report and canonical tags), rendering (what Google sees after JavaScript runs), speed (Core Web Vitals), and extras such as HTTPS, redirects and structured data.
How often should you do a technical SEO audit?
Check the Page indexing and Core Web Vitals reports monthly, run a full crawl every quarter, and always run the whole checklist after a redesign, a platform move or a domain change.
Can I do technical SEO myself?
Yes, on a small site. Search Console and a free crawler cover almost everything here. Rendering problems on JavaScript-heavy sites are the one area where you may need a developer.
What is the most important technical SEO factor?
Being indexed. Speed, structured data and everything else only help pages that are already in Google, so start with robots.txt and the Page indexing report.
Start with one report
If you only have half an hour, open the Page indexing report in Search Console and check every page you care about is indexed. That single check catches the problems that cost small sites the most traffic.
