This technical SEO checklist runs in the order problems stack up: can search engines find your pages, see them, index the right ones, understand them, and load them fast? Fix an earlier stage before a later one.
By Kristijan GjorgjioskiIndependent SEO consultantPublished 18 October 2026 · 10 min read
Technical problems are invisible until they cost you. A noindex tag left over from staging. A filter that spawns ten thousand URLs. A menu Google can't follow.
None of it shows up when you look at the page in a browser.
This technical SEO checklist gives you 24 checks, grouped by the question each one answers.
The order matters: a page Google can't crawl never gets indexed, however fast it loads. So work top to bottom, and don't skip ahead.
You need four free tools: Google Search Console, PageSpeed Insights, a site crawler and a browser with developer tools.
Then pick your starting point:
Pro tip: Save your first crawl. Every later crawl is far more useful when you can compare it with a baseline.
Crawling comes first for you, too. If Googlebot can't reach a page, nothing else on this list matters for it.
Open yourdomain.com/robots.txt and read every Disallow line.
Look for rules that block whole folders you need, such as /blog/ or /products/, and for a blanket Disallow: / left over from a staging site.
Remember what robots.txt is for.
Google's robots.txt introduction says it controls crawler access and is not a way to keep a page out of Google. A blocked URL can still be indexed if other pages link to it.
Pass: no money page or important folder is disallowed.
Your sitemap should list the URLs you want indexed, and only those.
Crawl the sitemap and check every URL returns a 200 status, isn't redirected, isn't noindexed and points its canonical at itself.
Then submit it in the Sitemaps report in Search Console.
Pass: the sitemap is submitted, read without errors, and contains only indexable canonical URLs.
Crawlers find pages by following links.
A page that's only in the sitemap, with no links pointing to it, is an orphan.
Compare your crawl with your sitemap. URLs in the sitemap but not found by the crawl are orphans. Also check click depth: my rule of thumb is that key pages sit within three clicks of the homepage. My guide to internal linking strategy covers how to fix this at scale.
Pass: every important page is linked from at least one other indexable page.
Links to 404 pages waste crawl effort and frustrate your visitors.
Filter your crawl for internal links returning 4xx codes.
Update each link to the right live URL, or redirect the dead URL if it had links or traffic.
Pass: zero internal links point to 4xx pages.
A chain is A to B to C.
A loop never ends. Both slow crawling and leak signals.
You'll find them in your crawler's redirect report.
Point every internal link and every redirect straight at the final URL.
Pass: every redirect resolves in one hop, and internal links point to final URLs.
Repeated 5xx errors tell Google your server is struggling, and it may crawl less as a result.
Open Settings, then Crawl stats, in Search Console.
Look at the response breakdown and the host status. Spikes in server errors or slow response times need a developer or your host.
Pass: server errors are rare, and no host status problems are flagged.
Your page can look perfect to you and nearly empty to a crawler.
This group catches that.
View the page source, which is the raw HTML, then compare it with the rendered DOM in developer tools.
If your main content, headings or links only appear after JavaScript runs, you're relying on Google rendering the page correctly.
Use the live test in Search Console's URL Inspection tool to see the HTML Google actually rendered.
Pass: main content and key links are present in the rendered HTML Google sees, ideally in the raw HTML too.
Google follows standard links: a elements with an href attribute.
Menus and buttons that move users with JavaScript click handlers alone often leave crawlers stuck.
Check your main navigation, pagination and filters in the rendered HTML.
Pass: every navigation path to an important page uses a crawlable link with a real URL.
If your content only loads when someone clicks, scrolls or hovers, a crawler may never see it.
Check tabs, accordions, "load more" buttons and lazy-loaded sections.
Text hidden in the HTML but revealed on click is usually fine. Text fetched only after a click is the risk.
Pass: important text exists in the rendered HTML without any user interaction.
Now check the index itself.
You want every page that deserves a place there, and nothing else.
In Search Console, open Indexing, then Pages.
Read the reasons listed under "Why pages aren't indexed".
Some reasons are healthy, such as redirects and deliberate noindex tags.
Others need action, such as "Crawled - currently not indexed" on pages you care about.
Pass: every important URL is indexed, and every exclusion reason is one you expect.
Google's guide to consolidating duplicate URLs lists redirects and rel=canonical as strong signals and sitemap inclusion as a weak one.
It also advises against using robots.txt or noindex for canonicalisation.
Crawl for canonicals that point to redirected, noindexed or 404 URLs, and for templates that canonicalise every page to the homepage.
Pass: each indexable page has a canonical pointing to itself or to its true primary version.
Thank-you pages, internal search results and thin tag archives usually don't belong in the index.
Use a noindex tag on them and leave them crawlable, so Google can see the tag.
Check the reverse too: noindex tags where they shouldn't be.
One translation company I worked with had a batch of fresh pages carrying exactly that instruction until I caught it.
Pass: noindex appears only on pages you chose, and none of them is blocked in robots.txt.
Sorting, filtering and tracking parameters can turn one of your pages into thousands of URLs.
Crawl with parameters included and count how many URLs each one creates. Decide which filter pages deserve indexing because people actually search for them, and keep the rest out with canonicals, noindex or by not linking to them. Stores face this most; technical SEO for e-commerce is mostly this problem. My explainer on crawl budget covers when it starts to matter.
Pass: parameter URLs in the index are ones you chose on purpose.
Near-empty pages, duplicated location pages and "no results" pages that return 200 all dilute your site.
Sort your crawl by word count and check the bottom.
Look for "Soft 404" in the Page indexing report.
Pass: each thin page is improved, merged, redirected or noindexed, and empty pages return a real 404.
HTTP and HTTPS, www and non-www, trailing slash and no slash: each pair should resolve to one version.
Type each variant of your homepage into a browser and a header checker.
All should 301 to the same URL.
Pass: every variant redirects in one hop to a single preferred version.
Once pages are crawled and indexed, make their purpose and relationships clear.
Group related pages under clear parent pages: services under a services hub, products under categories.
Readable folder paths and breadcrumbs reinforce that structure for visitors and crawlers alike.
Pass: you could sketch the site's structure as a tree, and the URLs follow it.
Schema markup describes your page for machines, so it must match what you can see on it.
Test key templates with Google's Rich Results Test and the Schema.org validator.
If you need to draft markup, the schema markup generator gives you valid JSON-LD to start from.
Pass: no errors on key templates, and every marked-up property is visible on the page.
Hreflang tells Google which language or country version to show each searcher. It breaks easily.
Check every version links to every other version and to itself, with return links in place.
My explainer on what hreflang is covers the rules, and the hreflang generator builds the tags for you.
Pass: every hreflang set is complete, reciprocal and points to indexable URLs.
Google indexes the mobile version of your pages.
If mobile hides content, links or structured data that desktop shows, that content may as well not exist.
Compare the two versions of your key templates side by side.
Pass: mobile shows the same main content, links and markup as desktop.
Speed comes last in the order, not in importance to visitors.
A slow page loses the enquiry before it loses a ranking.
Google's Core Web Vitals page sets the targets: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint under 200 milliseconds and Cumulative Layout Shift under 0.1.
Use the Core Web Vitals report in Search Console and the field data in PageSpeed Insights.
Field data reflects real visitors, so it outranks lab scores when they disagree.
Pass: your key templates meet all three targets in field data.
Oversized images are the most common speed problem I find.
Serve images at the size they display, in a modern format, and lazy-load anything below the first screen.
Never lazy-load the main hero image.
Pass: no image is much larger than its display size, and the main image loads first.
Chat widgets, tag managers, heatmaps and ad pixels add up fast on your pages.
List every third-party script with what it does and who uses the data.
Remove what nobody uses and delay what isn't needed on first load.
Pass: every script on the page has an owner and a reason to be there.
Lab tools run on fast machines.
Your customers often don't.
Load your key pages on a mid-range phone over mobile data.
Tap the main buttons, open the menu, fill in the form.
Pass: the page loads, responds and stays stable without frustrating delays.
Most technical damage I find arrives with a routine update, not the original build.
Schedule a monthly crawl and compare it with your baseline.
Turn on email alerts in Search Console. Before any big release, check staging for noindex tags, robots rules and changed URLs.
Pass: you'd know within a week if a release broke indexing.
A crawler will hand you hundreds of warnings. Most don't matter.
Rank each issue on two questions:
Group warnings by root cause, too. One template fix often clears hundreds of rows. That impact-first ordering is how I build the issue log in technical SEO engagements. If you want help reading a long report, my guide on how to read an SEO audit report explains what to fix first.
Don't try to clear all 24 checks in a week.
Run checks 1, 10 and 12 today.
Robots.txt, the Page indexing report and stray noindex tags take under an hour, and they catch the problems that hurt most.
Then work down the groups in order, starting with the templates that earn you enquiries or sales.
If your site runs on a JavaScript framework, has thousands of URLs, or you'd rather hand the fixes to someone who writes developer-ready tickets, that's where my technical SEO work comes in.
And if you suspect the problems go beyond the technical layer, a broader SEO audit reviews content and links as well.
A technical SEO checklist should cover crawling (robots.txt, sitemaps, internal links, redirects, server errors), rendering (JavaScript content and links), indexing (canonicals, noindex, duplicates, parameters), understanding (site structure, structured data, hreflang) and page experience (Core Web Vitals, images, scripts). It should end with ongoing monitoring, because releases often break things that were fixed.
Run a full technical check once or twice a year on a stable site, and a targeted check after every significant release, redesign or platform change. Between audits, keep an eye on the Page indexing and Crawl stats reports in Search Console and run a scheduled crawl, so problems show up while they are still cheap to fix.
You can run most of the checks yourself with Search Console, PageSpeed Insights and a crawler. Fixing them is another matter: template changes, rendering issues, redirects and server errors usually need a developer. Write each issue up with the affected URLs, what you expected, what you found and how to confirm the fix.
In the audits I run, the most common problems are index bloat and accidental blocking. Index bloat means thousands of low-value URLs, such as filters, tags or thin location pages, competing for attention with the pages that matter. Accidental blocking means a stray noindex tag or robots rule left over from staging or a plugin setting.
About the author
Kristijan Gjorgjioski
Independent SEO consultant · 6+ years in SEO · 60+ client websites worked on
I'm an independent SEO consultant with 6+ years in SEO. I run audits, migrations and content programmes for businesses in Europe, the UK and the USA, and I build the automation behind my own research.
Book a free 30-minute call. I look at your site first and tell you plainly what I would fix, and in what order.