Technical SEO, in the order the problems actually block you

The pipeline, and why order matters

Every technical SEO problem sits at one of five stages, and the stages are strictly sequential. A page that cannot be crawled will never be rendered. A page that renders empty will never be indexed usefully. A page that is indexed but ambiguous will never be understood well enough to be preferred.

This is why "we wrote 40 blog posts and nothing happened" is so often a rendering problem rather than a content problem. The content was real; it just never survived stage two.

Stage 1 — crawl access, including the crawlers people forget

Start by verifying access as a bot rather than as a browser, because the two can receive completely different responses. Shared hosts in particular run edge proxies with user-agent denylists that the site owner never configured and cannot see from a browser.

This is not hypothetical. The host this very site launched on returns HTTP 403 to seven AI crawlers before Apache ever reads robots.txt — a robots.txt that says Allow: / to everyone. The file was correct and irrelevant at the same time.

for ua in Googlebot Bingbot GPTBot ClaudeBot PerplexityBot Applebot CCBot; do
  printf "%-16s " "$ua"
  curl -s -o /dev/null -w "%{http_code}\n" -A "$ua/1.0" https://example.com/
done
# Every line must read 200. A 403 here overrules anything in robots.txt.

Stage 2 — rendering: what a crawler receives, not what you see

Open view-source, not DevTools. DevTools shows the DOM after JavaScript has run; view-source shows the bytes the server sent, which is what a non-rendering crawler gets and what Google indexes first.

If the body of view-source is an empty container, your content exists only after execution. Google will usually render it eventually through a deferred queue, but AI crawlers and many other consumers will not, and the delay is real. The fix is server-rendered or statically generated HTML — the same change that took this site from 73 words of crawlable text to a full document.

Stage 3 — indexation and duplication

• One canonical per piece of content, and it must be self-referential on the canonical URL itself
• Trailing-slash and non-slash variants resolve to one URL, not two 200s
• HTTP redirects to HTTPS in a single hop, and so does the www variant
• Parameters and tracking strings do not create indexable duplicates
• noindex is used deliberately — on thank-you pages, internal search results and staging — and never left behind after launch
• The XML sitemap contains only canonical, indexable, 200-returning URLs

Stage 4 — being understood: structured data and entities

Structured data is not a ranking factor in itself. It is a disambiguation mechanism, and disambiguation is what decides whether a search engine can associate your pages with a real business, a real author and a real set of services.

The minimum viable graph for a small business site is: an Organization, a Person, a WebSite, a WebPage per URL, a BreadcrumbList, and a Service or Product per commercial page — all linked by @id rather than repeated as loose islands. Loose nodes with no references between them are the most common structured-data mistake I find in audits, and they leave the graph meaning almost nothing.

Stage 5 — preference: speed, experience and evidence

Once several pages are crawlable, renderable, indexed and understood, the remaining question is why yours. Core Web Vitals contribute, and their contribution is smaller than most vendors imply and larger than zero — the honest framing is that they are a tie-breaker that also affects conversion directly, which is the better reason to fix them.

What moves preference more is evidence: pages that answer the query fully, an author with a traceable identity, and independent corroboration from other sites. The technical work makes you eligible. It does not make you preferred.

A prioritised audit order

1. Bot access by user-agent, including AI crawlers — a 403 here invalidates everything below
2. Rendering: view-source on your five most important pages
3. Indexation: coverage in Search Console versus your sitemap
4. Duplication: canonicals, protocol and slash variants, parameters
5. Structured data: does the graph link, and does it match visible content
6. Core Web Vitals: field data on the pages that carry sessions
7. Internal linking: orphans, depth, and anchor text
8. Freshness: dateModified that reflects reality rather than a build timestamp

Questions people ask about this

How often should a site be audited technically?

Once properly, then continuously and cheaply. A one-off audit ages the moment someone deploys. What actually holds is an automated check in the build that fails on regressions — missing canonicals, empty renders, broken links — which is how this site is set up.

Is technical SEO worth it for a small site?

For a five-page brochure site, the technical work is an afternoon and then it is done. For anything with a catalogue, filters or generated pages, it is the difference between being indexed and being invisible.

Do Core Web Vitals actually affect rankings?

They are a real but small ranking input, and a large conversion input. Fix them because slow pages lose customers; treat any ranking movement as a bonus rather than the business case.

Who wrote this

Anas Bin Masud builds e-commerce sites and does technical SEO for businesses in the UK, Canada and Pakistan — fifteen live client sites, six of them stores taking real payments. The examples in these guides come from those builds and from the audit that rebuilt this site, not from a content brief. More about how I work, or read the case studies.