Most technical SEO checklists are a list of everything, ordered by nothing. This one, written from the audits KM Digital Solutions runs on South African sites, is ordered by consequence: what stops a page existing in search at all, what makes Google pick the wrong version of it, what makes it unusable once someone arrives, and which popular checklist items are now obsolete and should be deleted from yours.
What is technical SEO actually for?
Making pages reachable, understandable and choosable. That is the whole job. Everything on a good checklist serves one of those three, and anything that serves none of them is housekeeping. Ranking is downstream of all three and is not something a checklist delivers on its own.
Ordering the work by consequence rather than by convention changes what you do first, because the items are not remotely equal in weight.
| Severity | What it looks like | Why it outranks everything below it |
|---|---|---|
| Fatal | The page cannot be reached, is blocked from indexing, or returns the wrong status code | Nothing downstream can matter. The page is not a candidate for anything |
| Serious | Several URLs serve the same content, or the canonical points somewhere unintended | Google indexes a version you did not choose, and your signals split across duplicates |
| Moderate | Thin or missing titles and headings, weak internal linking, an orphaned page | The page is understood poorly, or found only with difficulty |
| Real but slower | Slow rendering, layout instability, oversized assets | It costs you people who arrived, which is a conversion problem before it is a ranking one. How long the slower work takes to show is covered in how long SEO takes |
| Housekeeping | Markup tidiness, cosmetic warnings in third-party tools | Often reported loudest and worth the least. Do it last, if at all |
The reason to insist on that ordering is that commercial audit tools do not use it. They tend to report by count rather than by consequence, so a hundred cosmetic warnings look more urgent than a single blocked template, and teams spend a month on the wrong end of the list. Google makes the same point in a different context, noting that it does not evaluate or endorse third-party SEO tools and that those tools have no access to its internal ranking data, and advising you to check their recommendations against official guidance before making significant changes. KM Digital Solutions runs every audit against this severity order for that reason, and the first question on any site is always the same one: which pages that should exist in search do not. Everything else waits until that list is empty.
Can Google reach and index your pages?
Check in this order: is the page reachable by a link, does it return a 200, is it blocked in robots.txt, does it carry a noindex, does its canonical point at itself, and does it render its content without requiring a click. Any single failure ends the story, which is why this section comes first and why the order matters.
Step three is where the most expensive misunderstanding in technical SEO lives, and Google’s documentation contradicts it directly. A robots.txt file tells crawlers which URLs they may access, and Google states that it is not a mechanism for keeping a web page out of Google. Worse, a page disallowed in robots.txt can still be indexed if other sites link to it, in which case the URL and information such as anchor text can appear in results while the listing has no description, because Google was never allowed to read the page. To actually keep a page out you need noindex or password protection, and noindex only works if the crawler is permitted to fetch the page and see it. Blocking a page you also tagged noindex is a common self-defeating combination on sites that were built quickly and never re-audited.
Which version of a page should rank?
Exactly one, and you should be the one deciding. Duplicate and near-duplicate URLs are the second most common serious fault after access problems, and they are usually created accidentally by parameters, trailing slashes, protocol variants and printer-friendly copies rather than by anyone duplicating content on purpose.
Work through consolidation in this order, because each step reduces the noise the next one has to deal with.
- Pick the canonical URL deliberately for each piece of content, then link to it consistently from inside your own site. Google says linking consistently to the URL you consider canonical helps it understand your preference.
- Declare it in the HTML source. If the site renders with JavaScript, set the canonical in the source and do not let scripts rewrite it; if you cannot set it in the source, set it only with JavaScript rather than doing both.
- Redirect the genuine duplicates to the canonical with a permanent redirect, so people and crawlers arrive at the same place.
- Leave real dead ends dead. A page that is genuinely gone and has no equivalent should return 404 or 410 rather than being redirected somewhere irrelevant.
- List only canonical URLs in the sitemap, and remember what a sitemap is for: Google says it helps search engines discover URLs but does not guarantee that everything in it will be crawled and indexed.
- Re-check after any migration, because URL structure changes are where consolidation quietly comes undone.
Two things on that list are commonly overdone. Redirecting every 404 to the homepage is a habit rather than a fix, and it replaces an honest signal that a page is gone with a misleading one that it moved somewhere unrelated. Similarly, a sitemap is worth having but is not a lever: Google’s own guidance frames it as a discovery aid and lists the cases where it genuinely helps, which are large sites, new sites with few external links, sites with substantial media content, and sites where pages are not well linked internally. A small, well-linked South African business site with fifteen pages gets very little from sitemap effort beyond submitting one once, and the time is better spent on internal linking, which solves discovery and understanding at the same time. KM Digital Solutions treats internal linking as the higher-value job on almost every small site, and for a business that serves one area the same housekeeping feeds its local SEO.
Does the page work for the person who arrives?
Rendering and performance belong on the checklist, one step below access and consolidation. A page that is technically perfect and unusable still fails, and the failure shows up in enquiries before it shows up in rankings. The checks here are about the experience, not about a score.
Start with rendering, because it decides what exists at all. Content that only appears after a click, a scroll or a script that fails on a slow connection may not be seen, so the safest structure is that the important text is in the initial HTML. Then look at layout stability, which is mostly a matter of reserving space: images and embedded media with explicit width and height attributes do not shove the page around as they load. Then look at responsiveness to interaction, where the usual culprits are scripts doing work on every pointer or scroll event. The Chrome team’s guidance is specific about one common cause, advising you to avoid forced synchronous layouts and layout thrashing by reading style values before making style changes rather than interleaving the two. Finally, look at asset weight, which on a South African mobile connection is a real cost rather than a theoretical one.
What should you delete from your checklist?
Several items that were sound advice and no longer are. Checklists get copied forward for years, so the fastest quality improvement available to most audits is removing the entries that current documentation contradicts. Each of these is retired by a primary source rather than by opinion.
- “Add FAQPage markup for rich results.” Google has stopped showing FAQ rich results; its Search Central changelog records that the feature no longer appears in Google Search from 7 May 2026. Write FAQs for readers; never report rich results as a deliverable.
- “Add HowTo markup for rich results.” Google removed HowTo rich results from Search; its changelog records the removal of the documentation because the rich result is no longer shown. Keep step lists as ordinary visible content.
- “Add schema so AI systems cite you.” Google states there is no special schema.org structured data you need to add to appear in AI Overviews or AI Mode, and no new machine readable or AI text files either. Keep structured data matching your visible text, which Google does recommend, and read our guide to AI search optimisation for what actually changes.
- “Block it in robots.txt to remove it.” Covered above, and stated plainly by Google: robots.txt is not a mechanism for keeping a page out of Google.
- “Get every page indexed.” Not a goal. Thin, duplicated and utility pages are better left out, and Google notes that indexing is never guaranteed regardless.
- “Redirect every 404.” Only where a genuine equivalent exists. Otherwise the correct answer is to let it 404.
- “Fix Core Web Vitals and rankings follow.” Google’s page experience guidance says Core Web Vitals are used by its ranking systems, and also that good results in Core Web Vitals reports do not guarantee that your pages will rank at the top, because there is more to page experience than the scores alone. Fix performance for the people who arrive; do not sell it as a ranking lever.
The general principle underneath all of them is worth more than the list itself. Google’s guidance on evaluating SEO advice asks whether your provider cites official Google documentation as supporting evidence for its recommendations, and whether advice about optimising for AI experiences aligns with Google’s own published guidance on generative AI features. That is a usable test for any checklist item somebody hands you, including this one. If an item cannot be traced to current primary documentation, it is a convention rather than a requirement, and conventions are exactly what accumulate in a checklist that nobody has pruned, which is why this section exists at all and why it will need pruning again next year. Our SEO work re-derives the technical list from source each time rather than inheriting it, and the development side fixes what the audit finds instead of filing it.
Get the severity-ordered version for your site
We will tell you which pages are missing from search and why, which duplicates are splitting your signals, and which items on your current checklist are obsolete and can simply be deleted.
Frequently asked questions
Will blocking a page in robots.txt remove it from Google?
No. Google states that robots.txt is not a mechanism for keeping a web page out of Google, and that a page disallowed there can still be indexed if other sites link to it. In that case the URL can appear in results without a description, because Google was never permitted to read the page. To keep a page out of results, use noindex or password protection, and make sure the crawler is allowed to fetch the page so it can actually see the noindex.
Do I need a sitemap for a small business website?
Probably not much of one. Google frames a sitemap as a discovery aid and says it does not guarantee that everything listed will be crawled and indexed. It lists the cases where one genuinely helps: large sites, new sites with few external links, sites with a lot of video or image content, and sites where pages are not well linked to each other. A small site with good internal linking gets little beyond submitting one once.
Is a canonical tag a command or a suggestion?
Closer to a strong preference than a command. Google’s guidance is that linking consistently to the URL you consider canonical helps it understand your preference, which is a different thing from forcing an outcome. The practical implication is that your signals should agree with each other: the canonical tag, your internal links, your redirects and your sitemap should all point at the same URL. Contradictory signals are how the wrong version ends up indexed.
How often should a technical audit be repeated?
Whenever the site changes structurally, and on a light schedule otherwise. Migrations, template changes, plugin updates and redesigns are the events that reintroduce access and duplication faults, so those deserve a check immediately rather than at the next scheduled review. Between those events the useful habit is monitoring rather than auditing: watch which pages are indexed and which are not, and investigate the changes rather than re-running the full list.
Do Core Web Vitals decide my rankings?
No single metric decides rankings. Google says Core Web Vitals are used by its ranking systems, but that good results in reports like Search Console’s Core Web Vitals report do not guarantee that your pages will rank at the top of Google Search results, because there is more to great page experience than the scores alone. The honest reason to fix rendering and speed is the people who already reached your page and are deciding whether to wait for it, which is a conversion argument. Any ranking benefit is a bonus rather than the business case, and it is not something anyone can quantify for your site in advance.
The statement that robots.txt is not a mechanism for keeping a page out of Google, and that a disallowed page can still be indexed, is from Google’s Introduction to robots.txt. Canonicalisation guidance is from How to specify a canonical URL and sitemap guidance from the sitemaps overview. The absence of any special AI schema requirement is from AI features and your website, the FAQ and HowTo rich result removals from the Search Central changelog, the Core Web Vitals caveat from Understanding page experience in Google Search results, and the guidance on evaluating SEO advice and tools from Do you need an SEO?. The layout advice is from the Chrome team’s Avoid large, complex layouts and layout thrashing. All were accessed on 16 September 2026.
