Technical SEO: the complete checklist for 2026
Technical SEO makes sure search engines and AI crawlers can reach, render and index your pages. This checklist covers every layer, in the order to fix it.
Technical SEO is the work that lets search engines and AI crawlers find, fetch, render and index your pages. Check it in order: crawl access, indexing signals, site structure, rendering, speed, structured data and international setup. Fix what blocks indexing first, because nothing else matters on a page search engines cannot see.
This guide is the full checklist we use, one layer at a time, with a link to the deeper guide for each part. If you would rather hand the whole thing to a team, our technical SEO service runs it for you.
On this page
What is technical SEO, and how is it different from the rest of SEO?
Technical SEO is everything about your site that a search engine meets before it reads a single word. Content SEO decides what your pages say. Authority work decides who vouches for them. Technical SEO decides whether any of that reaches the index at all.
Google keeps the bar low on purpose. Its technical requirements come down to three things: Googlebot is not blocked, the page returns a working status code, and the page has indexable content [1]. Meeting that bar is easy for one page. Keeping it true for ten thousand pages, across every template and every release, is the actual job.
That is why technical SEO feels different from the rest of the work. Content improves slowly and fails quietly. Technical problems can take half a site out of the index in a single deploy. A developer adds a noindex tag to a staging template, the template ships, and a month of traffic goes with it.
It also means technical SEO is mostly about process. You need a list of checks, a way to run them after every change, and someone who owns the result. The checklist below is that list. Each layer depends on the one before it, so work through them in order.
| Layer | The question it answers | Where you look first |
|---|---|---|
| Crawl access | Can bots reach the page? | robots.txt, server status codes |
| Indexing signals | Will the search engine keep it? | noindex tags, canonicals, Search Console page indexing report |
| Structure | Can bots find it and understand where it sits? | Internal links, sitemaps, URL patterns |
| Rendering | Can bots see the content once the page loads? | URL Inspection, rendered HTML |
| Speed and experience | Is the page fast and stable for people? | Core Web Vitals field data |
| Structured data | Is the meaning of the page explicit? | JSON-LD, Rich Results Test |
| International | Does each market get the right version? | hreflang, language URLs |
Can search engines and AI crawlers reach your pages?
Start with access, because every other check assumes it. A crawler has to be allowed to request the page, the server has to answer, and the answer has to be a 200 status with real content in it.
The first file to read is robots.txt. It tells crawlers which paths they may request. It does not keep a page out of Google's index: a blocked URL can still be indexed from links if other sites point to it [2]. Use robots.txt to manage crawling, and use noindex to keep a page out of results. Mixing the two up is one of the most common mistakes we see, because a page blocked in robots.txt can never show the crawler its noindex tag.
Robots.txt now has a second audience. OpenAI, Anthropic, Perplexity and Google each run crawlers with their own user-agent names, and the rules you write decide whether AI assistants can read your pages. Our guide to robots.txt rules for AI crawlers lists the user agents and the trade-offs of allowing or blocking each one.
After robots.txt, check status codes. Every page you want indexed should return 200. Pages that moved should return a single 301 to their new home, not a chain of three hops. Pages that are gone should return 404 or 410. Watch for "soft 404s": pages that say "not found" to people but answer 200 to bots.
Then check what bots are actually doing, not what you expect them to do. Your server logs record every request from every crawler. Log file analysis shows which sections bots visit, how often, and where they waste time on URLs you never meant to expose.
Why are some pages not being indexed?
Crawled is not the same as indexed. Google fetches a page, decides whether it is worth keeping, and picks one version of it to store. The page indexing report in Search Console tells you which pages were left out and gives a reason for each group.
The reasons fall into a few buckets. Some pages are excluded on purpose, by a noindex tag or a canonical pointing elsewhere. Some are duplicates, and Google picked a different URL as the main one. Some were crawled but not indexed, which usually means Google did not think the page added enough. And some were discovered but not crawled yet, which often points to weak internal links or a slow server.
Read the reasons before you act. "Crawled, currently not indexed" on thin tag pages is Google doing you a favour. The same status on your main service page is an emergency. Our guide to fixing indexing problems walks through each status, what causes it and what to change.
Canonical tags deserve their own check. A canonical tells Google which URL you prefer when several show the same content. Google treats it as a strong hint, not a rule, and weighs it with redirects, sitemaps and internal links [3]. When those signals disagree, Google picks for you. The common failures are canonicals pointing to redirected URLs, to pages with noindex, or every page in a section pointing to page one. The full list is in canonical tag mistakes.
Finally, make sure your signals agree. The URL in your sitemap, the canonical on the page, the target of your internal links and the destination of any redirect should all be the same URL. One clean address per page removes most indexing guesswork.
How should your site structure, sitemaps and URLs work?
Structure is how crawlers find pages and how they judge which ones matter. Pages linked from your main navigation and from many other pages get crawled more and tend to rank better. Pages linked from nowhere, called orphans, may never be found at all.
Aim for a shallow structure. Your key pages should be reachable within three or four clicks of the homepage. Group related pages into clusters, with a main guide linking to each detail page and each detail page linking back. This article is built that way on purpose.
A sitemap is your list of the URLs you want crawled. It helps most on large sites, new sites with few links, and sites with lots of pages that change often [5]. A sitemap does not force indexing. It is a strong hint about which URLs matter. Keep it clean: only indexable, canonical URLs that return 200. The details of size limits, index files and lastmod dates are in our guide to XML sitemaps.
URL patterns matter too. Use short, readable paths with words, not IDs. Keep one pattern for each page type and never change it without a plan. Watch for parameters from filters, sorting and tracking, because each one can create a new URL for the same content.
Paginated lists are a special case. Category pages split across ?page=2, ?page=3 and beyond need to stay crawlable so products on deep pages get found. Each page should have its own self-referencing canonical, not one pointing to page one. Pagination SEO covers the patterns that work and the ones that hide your inventory.
Export every URL
Crawl the site and pull the URL list from your sitemap and from Search Console. Put them side by side.
Find the gaps
Pages in the sitemap but not in the crawl are orphans. Pages in the crawl but not in the sitemap are either missing from it or should not exist.
Check click depth
Sort by clicks from the homepage. Any page that earns money and sits deeper than four clicks needs a better link.
Clean the sitemap
Remove redirects, noindex pages, non-canonical URLs and errors. What remains is the list of pages you are asking search engines to keep.
Link the clusters
Make each main guide link to its detail pages and each detail page link back. Use anchor text that describes the page it points to.
Do search engines see your content once the page loads?
Rendering is where modern sites break most quietly. If your content only appears after JavaScript runs, a crawler has to download the page, run the scripts and wait. Google does this, but later and with limits. Many AI crawlers do not run JavaScript at all.
The test is simple. Use URL Inspection in Search Console and look at the rendered HTML. Then view the raw HTML your server sends, before any scripts run. If your main heading, body text and internal links are missing from the raw HTML, you depend on rendering. That is a risk for Google and often a blocker for AI assistants.
The fix is usually server-side rendering or static generation for the pages that matter. Frameworks such as Next.js make this the default, but it is still easy to push key content into client-only components by mistake. Our guide to JavaScript SEO in Next.js shows where content goes missing and how to check each route.
Watch links as well as text. Search engines follow <a href> links. Buttons that navigate with a click handler, or links built only after a script runs, may not be followed. The page looks linked to a person and looks orphaned to a bot.
Is your site fast enough, and do Core Web Vitals matter?
Speed matters for people first and rankings second. Google uses Core Web Vitals as part of its page experience signals, but a fast page with weak content will not beat a slower page that answers the question better. Treat speed as a tie-breaker for rankings and a real lever for conversions.
Core Web Vitals are three measures. Largest Contentful Paint (LCP) tracks how fast the main content shows up; the target is 2.5 seconds or less. Interaction to Next Paint (INP) tracks how fast the page responds to taps and clicks; the target is 200 milliseconds or less. Cumulative Layout Shift (CLS) tracks how much the layout jumps; the target is 0.1 or less. Google measures each at the 75th percentile of real visits [4].
That last point matters. Your score comes from field data, the experience of real visitors on their own devices and networks. A perfect lab test on your office laptop can hide a slow experience on a mid-range phone. Look at the Core Web Vitals report in Search Console, not only a lab tool.
The usual culprits are large hero images, too many third-party scripts, web fonts that block text, and ads or embeds without reserved space. Our Core Web Vitals guide explains how to find which one is hurting each metric and what fixes it.
Most of your visitors are probably on phones, so mobile is where speed is won or lost. Phones have slower processors, so heavy JavaScript hurts INP far more there than on desktop. Mobile speed optimization covers image sizing, script budgets and the fixes that move mobile scores the most.
| Metric | What it measures | Good score | Most common fix |
|---|---|---|---|
| LCP | How fast the main content appears | 2.5 seconds or less | Compress and preload the hero image; speed up the server response |
| INP | How fast the page reacts to input | 200 milliseconds or less | Cut and defer third-party scripts; break up long JavaScript tasks |
| CLS | How much the layout jumps | 0.1 or less | Set width and height on images, embeds and ad slots |
What does structured data do, and which types matter?
Structured data is code that states what a page is about in a format machines read without guessing. It tells search engines that a page is an article with an author, a product with a price, or a business with an address. It does not boost rankings on its own. It can earn rich results and helps both search engines and AI systems link your pages to the right entities.
Use JSON-LD, which is Google's preferred format, and keep it honest. The markup must describe what is visible on the page. Marking up reviews that are not shown, or prices that do not match, can cost you rich results.
For most business sites a short list covers it: Organization on the homepage, Article or BlogPosting on posts, Product on product pages, LocalBusiness if you have a physical location, and BreadcrumbList across the site. Start there and add more only when a type fits your content. Our guide to structured data basics shows the markup for each and how to test it.
Test after every template change. Structured data breaks silently: a missing field or a changed class name can remove it from thousands of pages at once. The enhancements reports in Search Console flag errors by type, so check them after each release.
How do you set up SEO for more than one language or country?
If you serve people in more than one language or country, you need to tell search engines which version belongs to which audience. The tool for that is hreflang: tags that link each page to its equivalents in other languages or regions.
Hreflang is simple in theory and fragile in practice. Every page must list itself and every alternate. Every alternate must link back. Language and region codes must be valid. One missing return link and the whole set can be ignored. Hreflang debugging lists the errors we find most and how to catch them before Google does.
Choose a URL structure before you choose tags. Subfolders like /fr/ keep all authority on one domain and are the simplest to run. Separate country domains give a strong local signal but split your links. Subdomains sit in between. Whatever you pick, keep it consistent and never use automatic redirects based on a visitor's location, because crawlers usually come from one country and would only ever see one version.
Right-to-left languages add their own checks: layout mirroring, text direction attributes and fonts that render correctly. Our separate guide to international SEO across markets, listed under related posts below, works through a multi-market setup, including one that runs English and Arabic side by side.
How do you keep a migration or redesign from losing traffic?
Migrations cause more lost traffic than any other technical event. A new domain, a new platform, a new URL structure or even a redesign on the same URLs can undo years of work if redirects, canonicals and content are not carried over.
The core rule is one old URL to one new URL, with a single 301 redirect, for every page that has traffic or links. Redirecting everything to the homepage throws away the value those pages earned. Redirect chains, where one URL hops through two or three others, slow crawlers down and leak value at every step. Our guide to 301 redirects for SEO explains when to use each status code and how to map redirects at scale.
Plan the move before anyone writes code. Crawl the old site, export every URL with traffic or backlinks, and build the redirect map. Keep titles, headings and body content the same on launch day wherever you can, so Google only has to process one change at a time. Then crawl the new site on staging and check that every old URL lands where it should.
Launch day is not the end. Watch indexing, rankings and server errors daily for the first two weeks and weekly for three months. The site migration checklist is the step-by-step list we use, from planning to post-launch checks.
Does crawl budget matter for your site?
Crawl budget is the number of URLs a search engine will crawl on your site in a given time. For most sites under a few thousand pages, it is not a problem worth solving. Google crawls small, well-linked sites fully without help.
It matters on large sites: online stores with filters, marketplaces, publishers and anything that generates URLs from parameters. There, bots can spend their time on millions of near-duplicate filter combinations while your new products wait days to be found.
The fixes are about waste, not about asking for more. Block crawl traps like infinite calendars and endless filter combinations. Remove internal links to URLs you do not want crawled. Fix slow server responses, because a slow server makes crawlers back off. Return real 404s for dead pages instead of redirecting them all. Our crawl budget guide shows how to tell whether you have a real crawl problem and which of these to do first. Pair it with log file analysis to see where the budget is going today.
How do you run a technical SEO audit?
A technical SEO audit is this whole checklist, run in one pass, with the findings ranked by what they cost you. A good audit ends with a short list of fixes, each with an owner and an effort estimate. It does not end with a 200-page export from a crawler.
You need three sources of truth. Search Console tells you what Google has done with your pages. A crawler tells you what your site looks like from the outside. Server logs tell you what bots actually requested. Each one catches problems the others miss, so use all three on any site with more than a few hundred pages.
Rank findings by impact and effort. A noindex on a key template is high impact and low effort: fix it today. A slow server is high impact and high effort: plan it. Missing alt text on old blog images is low impact: batch it for later. Our SEO audit template gives you the full checklist in a format you can copy, with columns for severity, owner and status.
| Problem | Search Console | Site crawler | Server logs |
|---|---|---|---|
| Pages dropped from the index | Yes, with a reason | No | Sometimes, as fewer bot visits |
| Broken links and redirect chains | Partly | Yes | Yes, as repeated 3xx and 404 hits |
| Wrong canonicals | Yes, as Google-chosen canonical | Yes | No |
| Bots wasting time on parameters | Partly, in crawl stats | Sometimes | Yes |
| Slow pages for real visitors | Yes, in Core Web Vitals | Lab data only | Server response times only |
How much does technical SEO cost, and how long does it take?
A technical audit is usually a fixed-fee project, and the fixes are usually developer time on top. Keep those two numbers apart in any quote. A cheap audit that produces a long list nobody can act on costs more in the end than a careful one with ten ranked fixes.
Timelines depend on what you find. Removing a stray noindex can bring pages back within days of the next crawl. Fixing site structure or rendering takes weeks of development and then weeks more for search engines to recrawl. A full migration clean-up can take a quarter. Anyone promising ranking gains from technical work alone, by a fixed date, is promising something that search engines control, not them.
Ongoing monitoring is cheaper than repair. Once the site is clean, a monthly check of the indexing, crawl stats and Core Web Vitals reports, plus a crawl after each release, catches most problems before they cost traffic. That is the part that fits well inside a retainer. Our plans and what they include are on the pricing page. We are an agency that sells this work, so weigh our view with that in mind, but the checklist above works the same whoever runs it.
What this guide covers next
Each layer above has its own detailed guide. Here is the full set, so you can go straight to the part you need.
- Core Web Vitals: what LCP, INP and CLS measure and how to fix each one.
- Mobile speed optimization: the fixes that move scores on real phones.
- JavaScript SEO in Next.js: making sure crawlers see content that scripts build.
- Fixing indexing problems: what each Search Console status means and what to do.
- Canonical tag mistakes: the errors that send Google to the wrong URL.
- XML sitemaps: building a sitemap that lists only the pages you want kept.
- Pagination SEO: keeping deep category pages crawlable.
- Crawl budget: when it matters and how to stop bots wasting it.
- Log file analysis: reading what crawlers actually do on your server.
- Robots.txt for AI crawlers: which AI bots to allow and which to block.
- Structured data basics: the schema types most sites need.
- Hreflang debugging: finding and fixing broken language tags.
- 301 redirects for SEO: which status code to use and how to map redirects.
- Site migration checklist: moving a site without losing traffic.
- SEO audit template: the whole checklist in a format you can copy.
Questions people also ask
How often should I run a technical SEO audit?
Run a full audit once a year and after any migration, redesign or platform change. In between, watch the indexing and crawl reports in Search Console every week, because most technical damage shows up there within days.
Can I do technical SEO without a developer?
You can find most problems without one, using Search Console and a crawler. Fixing them usually needs someone who can change templates, redirects and server settings, so plan for developer hours even if the diagnosis is yours.
Does technical SEO matter for AI search?
Yes. AI assistants and AI Overviews draw on pages that crawlers can fetch and read. A page that is blocked, broken or only visible after heavy JavaScript is a page no answer engine can quote.
What does a technical SEO project cost?
A one-off audit with a prioritised fix list is usually a fixed-fee project. Ongoing monitoring fits inside a retainer. The fixes themselves cost developer time, which is often the larger number, so ask any quote to separate the two.
Which technical problem should I fix first?
Fix anything that stops important pages being crawled or indexed first: blocked paths, noindex tags on live pages, broken redirects and wrong canonicals. Speed and structured data come after, because they only help pages that are already in the index.
Sources
- Google Search technical requirements — Google Search Central (checked 23 September 2026)
- Introduction to robots.txt — Google Search Central (checked 23 September 2026)
- How to specify a canonical URL with rel=canonical and other methods — Google Search Central (checked 23 September 2026)
- Web Vitals — web.dev (checked 23 September 2026)
- What is a sitemap — Google Search Central (checked 23 September 2026)
Want someone to run this checklist on your site?
Book a free 30-minute consultation with Ibrahem and Jeremy. We look at your site while we talk, and you leave with a prioritised plan.
Who wrote this
Ibrahem HelalCo-founder
Leads strategy and delivery.
Works on: SEO, GEO
Reviewed before publishing by Jeremy Zava, Co-founder.
- SEO Audit Template: What to Check and HowA working SEO audit template covering access, indexing, content, links and speed, with what to check in each layer and how to tell pass from fail.
- Indexing Problems: Why Pages Stay OutPages stay unindexed for a handful of reasons: low quality, a blocked crawl path, a wrong canonical, or Google simply choosing not to bother yet.
- Core Web Vitals: how to fix LCP, INP and CLSPass Core Web Vitals by fixing field data, not lab scores: find the slow template, fix LCP, INP and CLS in that order, then wait 28 days to confirm.
- Site Migration SEO: The Full ChecklistA site migration loses traffic when redirects, canonicals or content go missing. This checklist covers the mapping, the launch and the four weeks after.