The technical SEO checklist: 15 items ordered by what you can prove
Fifteen technical SEO checklist items ordered by the evidence your site can produce, from the Search Console reports that name URLs to the ones nobody can price.
Seven first-page results for this query, opened on 6 September 2026. Item counts of 10, 11, 23, 30, 31 and 32, plus one organised as four blocks rather than a list. One of the seven said why its items sit in the order they sit in. On a site that has been live for years that silence is the whole problem, because nothing on a technical list is urgent and something on it is already costing money.
What should a technical SEO checklist cover?
A technical SEO checklist covers indexing, canonicals, performance and rendering, ordered by the evidence your own site can produce. On a small site the Search Console reports settle almost everything; on a mid-size site a crawl adds orphans and redirect chains; past a million pages, crawl budget becomes a real constraint.
Quick answer
- Six of the fifteen items arrive already priced. A Search Console report names the affected URLs and counts them, so the cost of leaving the item alone is knowable rather than arguable.
- A check reporting "clean" is saying one of two things, and most tooling does not separate them: nothing is wrong, or nothing was measured.
- The bottom of the list is not wrong, it is unschedulable. Nobody can show you one URL it is costing you, which is exactly why it survives on retainers.
- Two things that first-page lists still ask for were removed by Google, one in March 2022 and one during 2024.
| Grade | The evidence available | Where it comes from | What the grade decides |
|---|---|---|---|
| One | A list of URLs with a count and a stated cause | Search Console reports | Work it this week; the cost is a number |
| Two | Evidence you produce, and producing it can fail silently | A crawl, a request, the served page | Build the check once, then break it on purpose |
| Three | None available at all | Nowhere | Do it if it is cheap; stop paying monthly for it |
Why a live site needs a different ordering criterion from a launch
Two orderings already work well on this blog and neither of them transfers. The launch checklist ordered by what cannot be undone works because publishing closes doors: the export of what the old site ranked for stops being possible the moment the new one goes up, so reversibility sorts the list by itself. That criterion needs an event to attach to.
So does the second one. A migration ordered by what stops being possible puts the redirect map first because the old site is about to disappear and take its structure with it. Again there is a deadline out in the world, and the deadline does the sorting.
A site that has been live for four years has no deadline. Nothing on its technical list becomes impossible next Tuesday. Reversibility ranks everything equal and timing ranks nothing at all, so both criteria collapse into the flat forty-box list this page opened by counting.
There is a third criterion on this blog and it is closer. The basic checklist ordered by return works for somebody with four hours a week and no report in front of them. It stops working the moment a crawler hands over a few hundred flagged issues, because return is a forecast about the future and a report is a claim about the present, and the two disagree constantly. Ordering by evidence is not the same as ordering by return. The item with the largest theoretical payoff is sometimes the one nobody can demonstrate, and that is a real cost of this ordering rather than an argument for it. What the ordering buys is the ability to say no: an item you cannot price cannot be compared against an item you can.
Six items whose evidence Search Console hands you
Somebody else already did the measuring. That is the entire distinction, and it is not a small one: each of these arrives as a cause, a count and a list of addresses. If the property is not connected the grade does not exist, and setting up Search Console is a fifteen-minute prerequisite for everything below.
1. Pages excluded from the index, read by cause and not by total
The page indexing report enumerates its reasons by name: server error (5xx), redirect error, blocked by robots.txt, excluded by a noindex tag, soft 404, not found (404), blocked by an unauthorized request, access forbidden, crawled but currently not indexed, discovered but currently not indexed, duplicate without user-selected canonical, duplicate where Google chose a different canonical, and page with redirect.
The total is the number people quote and the least useful figure on the screen. Which of those causes, on which URLs, and whether those URLs were ever meant to rank is the reading that turns the report into work. The catalogue of causes, one by one, is in why a page is not indexed.
2. The noindex that cannot be read, which is a different row from the one it resembles
Two of the reasons above are opposites that get treated as the same problem. Google's own wording settles it: "For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file, and it has to be otherwise accessible to the crawler."
That makes blocking a page in order to remove it the move that prevents its removal. It is the cheapest failure on this page to cause and one of the slowest to notice, because the site looks correct from every angle except the report.
3. Where a canonical declaration lost, named URL by URL
Google's canonicalization guidance, last updated on 20 August 2026, is unusually blunt about the status of the tag: "indicating a canonical preference is a hint, not a rule". The report row "Duplicate, Google chose different canonical than user" is the system telling you which of your suggestions it declined, and on which addresses.
Almost no checklist reads it that way. Most list "implement canonical tags" as a task that is either done or not done, which is a state the report does not have.
4. Core Web Vitals, on field data and on the current metric
The report in Search Console runs on field data from real visits over a 28-day window, grouped into URLs with a similar experience rather than measured one at a time. Good means a Largest Contentful Paint of 2.5 seconds or less, an Interaction to Next Paint of 200 milliseconds or less, and a Cumulative Layout Shift of 0.1 or less, assessed at the 75th percentile of page loads.
Interaction to Next Paint replaced First Input Delay in 2024, and one of the seven results I opened, the one written for enterprise sites, still lists First Input Delay among the metrics to monitor. Optimising a retired metric is not a small error: it aims the work at a number no report will ever show again. How to read this one without over-reacting to it is in Core Web Vitals in Search Console.
5. Rich result reports, but only for what the site actually claims
Structured data buys eligibility and nothing else. The documentation asks for the required properties to be present "for an object to be eligible for appearance in Google Search with enhanced display", and eligibility is not a position. Where a type is claimed, the rich result status reports name the pages carrying invalid items.
Where no type is claimed there is no report, no error and no item. A checklist listing schema as a universal task is assigning work to sites that have nothing to be eligible for.
6. Manual actions and security issues, the only zeros worth trusting
Two reports that are empty on almost every site, and the only two whose emptiness means what it appears to mean. They list actions taken by a reviewer or a system, so an empty report is an absence of actions rather than an absence of measurement. Every other zero in this article needs a second question attached to it.
Five items where you make the evidence, and the making can fail
No report covers this layer. The measurement gets built by whoever wants it, which means the measurement becomes the risk: this is where a check that has never fired gets mistaken for a site that has never broken.
Scale decides what is affordable. Under a hundred pages the whole layer is an afternoon of manual checks; at a few thousand it needs a crawler and a saved file to compare against next quarter; past a hundred thousand it needs sampling and an explicit statement of what was not looked at.
7. What the domain serves, which is not what the origin serves
I replaced the portrait on this site on 27 August 2026. The deploy was correct and the origin was serving the new file. The owner kept seeing the old one, and he was right: the domain returned 88,111 bytes with cf-cache-status: HIT while the origin returned 49,051, cached with max-age=86400 and stale-while-revalidate=604800.
The verification I had run was the one written in my own manual, and it was still insufficient. Resolving the hostname to the host's IP tells you what got deployed. Only a request to the domain tells you what a visitor receives, and between those two answers sits a cache with no reason to expire anything. The repair was a fingerprint in the URL rather than a purge, because a purge depends on somebody remembering and a fingerprint does not.
8. Rendering, meaning the HTML the crawler actually receives
What the browser paints after its scripts run and what arrives in the initial response are two documents. The live test in URL Inspection returns the rendered HTML, and comparing it against the source is the only version of this check that produces evidence rather than an opinion about JavaScript.
9. The internal link structure, which no report can show as an absence
A report can list the links that exist. It cannot list the ones that do not, and an orphan page is defined entirely by absence. That asymmetry is why orphans survive audits: every tool shows inbound link counts, and a page with none simply does not appear in the table. Why this layer outranks most of what gets prioritised above it is argued at length in what SEO is and what it is for.
10. Redirect chains, and internal links that only work through a hop
Each internal link resolving in one hop to a page that answers 200, rather than through a rule in a configuration file. Chains work for visitors, so nothing complains, and the day somebody prunes the oldest rule the middle of the chain disappears. The evidence is a crawl, and the useful column is not the count of redirects but the count of internal links pointing at one.
11. hreflang, which Search Console no longer validates
The International Targeting report was deprecated, and Google's own notice on it keeps the annotation alive while taking the validation away: "Google will continue to support and use hreflang tags on your pages." The signal still counts and the report that used to check it is gone.
On this blog a language pair is declared only when both halves point back at each other, because half a signal gets discarded whole rather than counted at half weight. The rest of what running one site in two languages costs, including the cases where the pair should not be declared at all, is in translating a website for SEO.
Four items nobody can price
Nothing here is a lie. Each of these is defensible, cheap enough to do, and impossible to attach to a single URL that is losing something today. That combination is what makes them the permanent furniture of a monthly invoice.
12. Structured data past the point where it earns a rich result
The failure mode is what makes this one impossible to police: valid JSON-LD whose internal relationships are silently ignored. Building the category pages of this blog, the first version shipped twelve dangling @id references pointing at a node that existed only in another page's graph. Every validator passed the file, because the file was valid. An @id resolves only inside the graph of its own page, and the response to a reference that cannot be resolved is to drop the relationship without an error anywhere.
I caught it because a check of mine fails the build on dangling references, and because I had broken one on purpose once to confirm that it fired.
13. AI text files, including the one I publish
Google's guide on optimising for generative AI features, last updated on 10 July 2026, names this category by name: it asks readers to "prioritize effective SEO strategies over 'AEO/GEO hacks'" and says that for Google Search "you can ignore tactics like 'chunking' content, creating unnecessary AI text files (like llms.txt), or pursuing inauthentic mentions."
This site publishes an llms.txt and two tools around it, so the item is mine as much as anyone's. What puts it in this grade is not uselessness. It is that nothing reports on it. In September 2026 my own file had grown to 94 links while the validator this site publishes warns above one hundred, and the only reason I found out is that I went looking. What the file is, who reads it and what it changes at each size is in what llms.txt is.
14. Items that check something that stopped existing
Three examples, all of them still present on first-page results for this query.
- URL parameter handling. Google deprecated the URL Parameters tool on 28 March 2022 and published its own measurement of what it had been worth: "only about 1% of the parameter configurations currently specified in the URL Parameters tool are useful for crawling." Two of the seven results I opened still send the reader to parameter handling in Search Console.
- The next and previous link relations. The pagination guidance is explicit: "Google no longer uses these tags, although these links may still be used by other search engines."
- First Input Delay, covered above, still listed as a metric to monitor.
Nothing ever comes off these lists. Items get appended when something appears and nothing gets removed when something dies, because every line takes one row and every row looks equally alive.
15. Crawl budget on a site that does not have one
The crawl budget guide opens by telling most of its readers to leave: "If your site doesn't have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don't need to read this guide."
It names its audience as sites in the millions of pages, or in the tens of thousands with content changing daily, or with a large share of URLs sitting in "Discovered, currently not indexed". Outside those three shapes it consumes attention and returns nothing measurable.
When this ordering is the wrong one
When traffic just fell. Then the question is not which item to work but what changed, and the answer lives in a comparison against a fixed cohort rather than in a checklist, which is the argument of why organic traffic drops.
When the site is not live yet, or is about to move. Both of those have deadlines, and a deadline is a better sorter than evidence.
When the grade one reports are already empty. The evidence has run out at the top of the list, and the useful work sits in grade two, which is the only layer producing new information about a site nobody is currently breaking.
When somebody is charging monthly for grade three. The reading that follows from this page is uncomfortable and worth having anyway, and it belongs beside the other signs in whether an SEO agency is working.
Mistakes that repeat
- Reading the page indexing report by its total. The total mixes URLs that were never meant to rank with URLs that were, and the two need opposite responses.
- Blocking a page in robots.txt to get it removed. The block stops the noindex directive from being read, so the page stays in and the fix stays invisible.
- Treating a canonical tag as a decision. It is a hint, and the report says where it lost.
- Trusting a green result from a check that has never failed. Absence of findings and absence of measurement produce identical output on most tooling.
- Verifying a deploy against the origin. The origin says what was published, and only the domain says what a visitor gets.
- Keeping every item forever. A list that never removes anything eventually spends most of its rows on retired features.
Data and transparency
The reasons enumerated in the page indexing report, the requirement that a page carrying a noindex directive not be blocked in robots.txt, the description of a canonical as "a hint, not a rule", the eligibility wording for structured data, the statement that Google no longer uses the next and previous link relations, the audience the crawl budget guide names for itself, and the note that Google continues to support hreflang after removing the report that validated it, all come from Google's own documentation and Search Console help pages, each one opened on 6 September 2026 and linked below. The Core Web Vitals thresholds and the assessment at the 75th percentile come from the Search Console help page for that report and from the Web Vitals reference, opened the same day.
One detail worth recording for anyone citing these pages. Google's crawling documentation moved during 2026 into a section of its own, so search/docs/crawling-indexing/large-site-managing-crawl-budget now redirects to crawling/docs/crawl-budget, and several old paths return 404 outright instead of redirecting: search/docs/crawling-indexing/robots/robots_meta_tag is one, checked the same day. A citation to third-party documentation ages without announcing itself.
No figure appears here for how many sites have any of these problems, and none for what fixing one returns. Numbers of that kind circulate widely for technical SEO and none I checked traces back to a stated sample. What is described instead is the mechanism and where the evidence for it lives, which is checkable by anyone on their own property.
The item counts are my own observation of seven first-page results on 6 September 2026, recorded as a pattern in the results rather than as a source, along with which of them still list First Input Delay or parameter handling. The replaced portrait, with 88,111 bytes served at the domain against 49,051 at the origin, and the twelve dangling @id references in the first version of this site's category pages, come from this site's own operations log for August and September 2026. The general criterion comes from audit work across a portfolio recording more than 300 million impressions a year in Google, on the sites I operate. Verified as of September 2026.
Primary sources, opened on 6 September 2026: the page indexing report help page, blocking indexing with a noindex directive, canonicalization, the Core Web Vitals report help page, the Web Vitals reference, the structured data introduction, the pagination guidance, the URL Parameters tool deprecation, the crawl budget guide, the International Targeting deprecation notice and the guide to optimizing for generative AI features.
What this changes
The number a technical audit produces is an issue count, and an issue count describes the tool rather than the site. It counts deviations from whatever template the crawler was built around, so swapping the crawler changes the total without a single click moving in either direction.
Sorting by evidence dissolves that number into three piles of very different value, and the uncomfortable pile is the third. Not because those items are wrong, but because an item nobody can price is an item nobody can finish, and work that cannot be finished is the most reliable thing in this industry to sell by the month.
The zero worth being suspicious of is not the one in the issue count. It is the one in your own checks. A probe of mine reported clean for weeks while measuring nothing at all, because the code inside it threw an error, returned an empty result, and the surrounding script read empty as nothing to report. A broken check and a healthy page produced the same string, and there is no report anywhere that catches that.
Frequently asked questions
What is included in a technical SEO checklist?
Indexing, canonicals, performance, rendering, internal link structure and the international annotations where a site has them. The division that helps is not by category but by evidence: six of the items on this page are reported by Search Console with the affected URLs named, five require a crawl or a request made by hand, and four cannot be attached to any URL at all.
How often should a technical SEO audit run?
The grade one reports repay a monthly read, because they change on their own as Google recrawls and the change arrives already sorted by cause. The grade two layer is a quarterly job on a stable site and a per-deploy job on one that ships often, since that is when rendering, redirects and cache behaviour move. Grade three needs no cadence.
Does structured data improve rankings?
It buys eligibility for enhanced display, which is a different thing. Google's documentation asks for the required properties so an object is eligible to appear with enhanced display, and eligibility is not a position. On pages claiming no rich result type it changes nothing, which is why a checklist listing schema as universal work assigns effort to sites with nothing to be eligible for.
Is crawl budget worth worrying about on a small site?
Google's own crawl budget guide says no, in its opening lines, for any site whose pages are crawled around the day they are published. It names its audience as sites with pages in the millions, or in the tens of thousands with daily changes, or with a large share of URLs reported as discovered and not indexed. Outside those shapes the item returns nothing measurable.
Why does my SEO audit tool report hundreds of issues?
Because it reports every deviation from a template rather than every loss on the site, and those are different lists. A crawler cannot know which pages were meant to rank, so it flags all of them equally. The reconciliation is checking each flagged item against a Search Console report that names URLs, and dropping whatever no report can see.
Most sites do not have a ranking problem
They have a what-happens-next problem. You can rank first and still sell nothing. The diagnostic looks at both and tells you which one is costing you money.
See the diagnostic