Technical SEO wins that survive the next algorithm update

Every core update produces the same cycle: rankings move, someone publishes a theory, and teams rewrite things based on it. Most of that work is wasted, because it targets a mechanism rather than a cause.

The technical work that holds its value has a common property — it would still be worth doing if search engines did not exist. It makes the site faster, clearer, better structured and easier to understand. That is why it survives updates.

Make every URL state one unambiguous truth

Canonicalisation is the least glamorous item on this list and the one that causes the most damage when it is wrong. The failure is rarely dramatic; it is a slow dilution of signals across duplicate URLs.

Get these four aligned, and keep them aligned:

1. 01Pick one host and one scheme. www or apex, https always. Everything else redirects to it with a 301, in a single hop.
2. 02Self-referencing canonical on every page, pointing at the exact URL that serves a 200.
3. 03Sitemap lists only canonical, `200`-returning URLs. A sitemap full of redirects tells a crawler your declared URLs are not your real ones.
4. 04Internal links use the canonical form. Linking internally to a URL that redirects wastes crawl budget on every single crawl.

# Does the sitemap URL actually resolve, or does it redirect?
curl -sSI https://example.com/ -o /dev/null   -w '%{http_code} -> %{redirect_url}
'

# And does the page agree with itself about its own address?
curl -sS https://www.example.com/ | grep -i 'rel="canonical"'

Structured data as a description, not a decoration

Schema markup is increasingly how a machine reads a page — for rich results, and now for whether an answer engine can cite you with confidence. The mistake is treating it as a checklist of types to emit rather than an accurate description of the page.

Two rules cover most of it. It must match the visible content — marking up a review that does not appear on the page is a manual-action risk, not a clever shortcut. And entities should be connected with `@id` rather than repeated, so the graph describes one organisation rather than fifteen unrelated mentions.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Studio",
      "url": "https://example.com/",
      "sameAs": ["https://www.linkedin.com/company/example"]
    },
    {
      "@type": "Article",
      "@id": "https://example.com/blog/post/#article",
      "headline": "Technical SEO wins that survive",
      "datePublished": "2026-03-11",
      "author":    { "@id": "https://example.com/#organization" },
      "publisher": { "@id": "https://example.com/#organization" },
      "isPartOf":  { "@id": "https://example.com/#website" }
    }
  ]
}

The @id references are what turn a pile of snippets into a graph. A crawler can then resolve that the article author and the site publisher are the same entity, with a LinkedIn profile that corroborates it — which is the actual point.

Spend crawl budget on pages that matter

On a large site, crawl efficiency is a real constraint. On a small one it matters less, but the habits that waste it also confuse users, so they are worth fixing regardless.

• Do not let faceted navigation generate infinite URLs. Every filter combination as a crawlable link is the classic way to bury 200 real pages under 40,000 parameterised ones.
• Return the right status codes. A missing page that returns 200 with "not found" text — a soft 404 — keeps getting crawled forever.
• Keep redirect chains to one hop. Chains lose signal at each step and burn budget.
• Do not block resources the renderer needs. If CSS or JS is disallowed in robots.txt, the page is assessed without its layout.
• Prune, merge or noindex thin pages. Fewer, better pages beat more, weaker ones — including the auto-generated tag archives most CMSs produce by default.

Internal linking is the most under-used lever

It is entirely under your control, costs nothing, and most sites do it poorly. Three things to check:

1. 01Click depth. Anything more than three clicks from the home page reads as unimportant. If it is not, shorten the path.
2. 02Descriptive anchors. "WordPress performance work" tells a crawler and a reader what is on the other end. "Read more" tells neither.
3. 03Orphan pages. A page in the sitemap with no internal links pointing at it is a contradiction — you have declared it important and then linked to it from nowhere.

Performance is a ranking input and a conversion input

Core Web Vitals are a modest ranking signal and a very large conversion signal, which makes them unusually easy to justify. The work is the same either way: server-render what matters, do not lazy-load the hero, reserve space for images, keep third-party scripts on a short leash.

The durable framing is that you are not optimising for a crawler. You are removing reasons for a person on a mid-range phone to leave, and the ranking benefit follows from that rather than the other way around.

Build for answer engines the same way

LLM-driven search changes the surface, not the substrate. What makes a page citable is what already made it rankable: a clear heading structure, a direct answer near the top, factual precision, accurate structured data, and an identifiable author. Pages that hedge for 800 words before answering do badly in both.

A small, practical addition is an llms.txt at the site root — a plain-text summary of what the organisation does and which pages matter. It costs an hour, and it is the same instinct as a sitemap: tell the machine what is here rather than making it infer.

What to check every quarter

• Index coverage: pages you want indexed that are not, and pages indexed that should not be.
• Sitemap health: every URL returns 200, no redirects, no orphans.
• Core Web Vitals at p75 from field data, segmented by device.
• Structured data validity, and whether it still matches what the page shows.
• Redirect chains introduced by the last few releases.
• Broken internal and outbound links.

None of this is exciting. All of it compounds, and none of it is undone by the next update — which is the whole argument for doing it in this order.

If a tactic would stop being worth doing the moment search engines changed their minds, it was never technical SEO. It was a bet.