The Technical SEO Checklist Every Web Developer Should Ship in 2026

The most expensive SEO bug I ever debugged was invisible in every browser. A client's product pages had gorgeous canonical tags, clean HTML, fast loads — and Google had quietly indexed exactly one of their many filter combinations, treating the rest as duplicates, because a single line in their middleware appended a harmless tracking parameter to internal links. No console error. Every Lighthouse run green. The rankings were distributed across a dozen technical variants until each one became too weak to rank for anything. Three weeks to find; one line to fix.

I tell that story because "technical SEO" has a reputation as something an agency sprinkles after launch, and the truth is the inverse: it is engineering, it fails for engineering reasons, and the people who must own it are the people who control the markup — developers. This is the checklist that I ship on every production build, including this one, and the reasoning behind each item, so you can argue with it intelligently rather than obey it blindly.

Canonical URLs: one address per page, for real

Every page emits a canonical link to its own absolute production URL — including trailing-slash variants, query variants (except deliberate pagination), and staging derivatives that accidentally reach a crawler. Canonicals sound trivial until you meet the failure modes, which are all silent:

• Relative canonicals resolve inconsistently and quietly split signals.
• Per-environment canonicals claiming staging as the truth, from templates that were never parameterized for production.
• Self-referencing pages that canonicalize to a filtered variant because one stateful link generator had a bad day.
• THE middleware parameter story above — the worst class, because nothing looks wrong.

In a Next.js build, canonicals come from the same metadata helper everything else uses (my App Router guide shows the pattern), and CI asserts on rendered HTML for each route: title unique per page, description present and in range, canonical exactly equal to the production URL pattern. When a contract covers managing this myself, that assertion is one of the first things I add, because the regression it prevents is invisible until money evaporates.

Titles and meta descriptions: written per page, not generated per template

Templates generate structure; humans write content. The failure pattern is title-tag monoculture: "Product | Brand" repeated across forty product pages with only the product name differing — technically fine, strategically disastrous, because it wastes the one field where Google rewards specificity and users compare listings.

My working standards: title lengths near 50–60 characters ({absolute} titles so templates cannot append a second "| Brand" on top of the page's own); descriptions 140–160 characters written as actual ad copy, with verbs and differentiation; and — this one matters more than most people credit — re-read them on the rendered page, because template concatenation bugs (my portfolio had a doubled brand for two weeks once; Search Console's page-experience report found it before I did) only show in the final DOM.

Structured data: describe exactly what the page shows

Schema.org JSON-LD is the part of technical SEO where Google's own guidance and developer instincts diverge most, so the rules I hold are narrower than the tutorials suggest:

• JSON-LD only, emitted server-side in the page HTML — not injected client-side, not from a tag manager, which introduces a rendering dependency for a crawler feature.
• Only types matching real page content, verified entity-by-entity. FAQPage markup only where actual visible FAQ content lives on the page; Article with real published/updated dates; Person/author with sameAs that resolves; SoftwareApplication for actual products with real offer data. Inflated structured data gets manual warnings, which are permanent records attached to your domain.
• One source of truth: structured data built from the same data structures that render the visible page. When the two drift, rich results die quietly — and they die hardest on data-driven pages (prices, availability, publish dates) where staleness reads as dishonesty to the crawler.

Validate ruthlessly and continuously: Search Console enhancements reports plus a CI smoke test that scrapes JSON-LD per template and validates required properties. The first time a CMS edit fills a field with undefined, you want the build red, not a visit from a manual action six weeks later.

Sitemaps: fresh signals over complete fiction

A sitemap should be generated from your data layer, not hand-maintained: published posts with honest lastmod dates (real updated_at, not "now" — fake freshness teaches crawlers to distrust your dates), page sitemap for static routes, and image sitemaps for pages where imagery carries the product — because image search is a discovery channel most teams leave entirely unclaimed.

And the boring hygiene that separates a live sitemap from a decorative one: it 200s from the canonical host, is referenced from robots.txt, contains no URLs that redirect or 404 (Google treats persistent junk sitemap entries as noise, which is exactly what you do not want your primary discovery signal to become), and its freshness dates actually change when content changes. A sitemap with a static lastmod is a wristwatch with a stopped hand — technically right twice a day and never when needed.

Machine-readable surfaces: robots, llms.txt, feeds

Three artifacts most teams ship half-heartedly, each costing an afternoon:

• robots.txt that neither over-blocks (the classic: Disallow: / on staging propagating to prod by copy-paste) nor wastes crawl budget on admin, API, and search-result paths.
• llms.txt — in 2026, AI-assistant crawlers are a reconstruction of the old problem (machines summarizing your site), and an llms.txt giving your key pages, services, and product list a machine-readable summary is cheap insurance for a channel that is growing whether anyone approves of it or not.
• RSS/Atom feed — old tech, still a distribution surface: aggregators, readers, and increasingly AI-era republishing pipelines consume feeds. Half an hour of work; a permanent subscriber channel.

Index-worthiness: the meta-discipline

The most useful concept I can hand you from a decade of watching these failures: index-worthiness beats cleverness. A crawler's decision to index a page is a quality judgment, and every item above exists to make that judgment easy:

• Content in server-rendered HTML. Client-only content that fetches after hydration gets "crawled, currently not indexed" with remarkable consistency. If it must be indexed, it must be in the first HTML.
• Internal links with descriptive anchors, enough of them, from related content. Orphan pages (linked from nowhere) and pages only reachable through filters rank like they deserve to.
• No login-free duplicates: paginated, filtered, and printable variants canonicalized or noindexed deliberately, not accidentally.
• 404s return status 404. Soft-404 templates confuse crawlers about quality more than honest 404s do.
• One truly unique title per indexable page. Title cannibalization is still the most common self-inflicted SEO wound I see in audits.

The quiet killers, collected

The bugs that actually eat rankings, from the field:

1. metadataBase misconfigured — every OG image broken on social; link CTR dies invisibly.
2. Metadata shallow-merge misunderstanding — page-level openGraph replacing the root config and dropping siteName/images on some routes only.
3. Staging canonicals on production, from copy-pasted templates.
4. Trailing slash duplication splitting one page's signals into two URLs.
5. Redirect chains from old campaigns — crawler budget, diluted link signals.
6. Sitemap with yesterday's lastmod — freshness signal converted to noise.
7. JS-only content — the index-worthiness failure wearing a modern framework's costume.

Everything on this list is checkable. So check it in CI, not in your memory — and this portfolio's surfaces are all live if you want to inspect the implementation: sitemap.xml, feed.xml, llms.txt, and the JSON-LD in every page's source.

FAQ

How do I know which pages Google actually indexes? Search Console's Pages report — the "Crawled, currently not indexed" bucket is where weak pages go, and it is a gift: a specific list of URLs you can improve or consolidate.

llms.txt — is it real SEO in 2026? It is an emerging, low-cost surface with growing consumer usage (AI-assistant crawlers). I treat it like structured data pre-2015: cheap to ship, benefit uncertain, downside zero. Not a ranking factor on any documented list; a distribution surface like an RSS feed.

Does PageSpeed equal technical SEO? No — performance is one pillar (see my Core Web Vitals piece). The other pillars — canonicals, structured data, crawl efficiency, internal linking — fail independently, and audits that only measure Lighthouse miss them wholesale.

How often should I re-audit? Every major release candidate, plus a scheduled quarterly pass against Search Console reports. The checklist automates most of it; the quarterly habit catches the drift the automation cannot see — business changes that alter crawl priorities.

Who should own technical SEO on a product team? Whoever controls the markup — engineers, with SEO-literate review. The alternative, an agency "optimizing" outside the code, produces recommendations nobody implements, which depreciate into nobody's KPI.

Internal linking and site architecture: shaping crawl flow

Canonicals and sitemaps get all the beginner attention; internal linking is where the durable ranking power lives, and it is the item most likely to be entirely missing from a developer's checklist. The ideas worth engineering:

• Flat-(-ish) architecture: every valuable page within a few internal hops of the homepage. Depth is not a ranking law, but every structural level multiplies the "does anyone even link to this?" problem — orphan pages almost always live deep, because nobody revisits what they cannot see.
• Descriptive anchors, placed by relevance: in-content links from related pages carry more weight than link lists bolted into footers. My blog's cross-linking (this article linking to the App Router guide, the case study linking to the SEO checklist) is the pattern — contextual, mutually reinforcing, real.
• Hub pages that consolidate topic authority: a services page linking to its case studies; a category index linking to its articles. Hubs also give crawlers a scan-efficient map — which is visible in crawl-stat reports as them clustering around your hubs.
• Fix orphan pages deliberately: compare sitemap URLs against pages reachable by crawling your internal links. Sitemap-only pages submit weakly; a link from a related page upgrades them more than any resubmission will.

Pagination and faceted navigation without the classic wounds

List-heavy products create the sequel problems most audits miss until rankings sag:

• Pagination: pages self-canonicalize; titles differentiate ("Page 2 of …"); noindex-sparse pages deliberately rather than letting endlessly empty tails accumulate. Which tail pages deserve indexing is a product decision made consciously, not by crawl defaults.
• Filter-faceted URLs: indexable only the facets with real search demand; canonicalize or noindex the combinatorial rest. Faceted explosion is the number-one crawl-budget dev road: unmanaged, thousands of near-duplicates form and the site's quality profile dilutes them all.
• Sort orders and session params: canonicalize away transparently; they are the least controversial canonicalization most sites still miss.

Multi-language and hreflang: the mechanical discipline

If your product serves more than one locale, the hreflang pair rules are unforgiving and mechanical: bidirectional, self-referential, and consistent with canonical logic. A Spanish page declares itself es, its en alternative — and the en page mirrors the declaration exactly. The failure mode nobody warns about is canonical/hreflang conflict: a hreflang tag pointing at a URL that is canonicalized elsewhere gets ignored entirely, and a locale silently drops from results. The ISO-region branches (es-419 vs es-ES) matter for implementation quality, and Search Console's international-targeting reports surface the breakages if you actually check them.

Migration engineering — the highest-stakes day in SEO

Domains move, architectures rebuild. A migration's checklist is the checklist above plus five critical additions, and the stakes justify repeating them:

1. URL inventory and mapping, with 301s one-to-one — no mass redirect to the homepage, the classic inventor-wound.
2. Pre-index the new architecture for staging crawl validation, canonicals correct, before DNS flips.
3. Post-flip crawl monitoring, daily for two weeks: status codes, redirect chains, canonical integrity, indexation drift compared week-over-week.
4. Preserve site-structure signals: keep old sitemaps temporarily, keep author pages, keep the deep content links intact.
5. Communication to Search Console — and expect a temporary volatility window; the teams that panic and mid-flip the mapping create the losses they feared.

Image SEO — the discovery channel most sites leave idle

Image search drives real product discovery in commerce, portfolios, and how-to content, and it is won by machine legibility rather than beauty:

• Descriptive filenames and rich alt text written for what a person needs in an image search — not keyword-stuffed captions nobody would read aloud. "Tillqorin POS retail dashboard with thermal receipt printer" beats "dashboard-final-2.png" in every measurable way.
• Image sitemap entries for the images that carry product meaning (not for decoration), with titles and captions where they genuinely describe.
• Surrounding context matters: search engines read the text around an image to classify it. A product photo inside descriptive product copy is legible; the same photo inside a carousel div is anonymous.
• Format and serving quality feed back: fast-loading, correctly-sized images get crawled more effectively — the Core Web Vitals work and the image SEO work converge on the same asset pipeline.

One overlooked behavior worth nurturing: your public case pages are also image sources. When developers and journalists describe real products, they screenshot them. Providing clearly labeled screenshots and letting them be found is free distribution — one of those SEO channels that costs content discipline instead of tooling money.

Crawl budget sanity for real sites

Most sites never exhaust their crawl budget; growing sites hit it and misread the symptom as "Google is slow." The indicators: many discovered-not-indexed pages, crawl-stat discrepancies in Search Console, and stale updates on pages that changed. The engineering remedies, in order of usual impact:

• Eliminate crawlable duplicates (the faceted-navigation discipline above) — budget spent on dupes is budget not spent on your real pages.
• Return proper 410s for retired content rather than soft-404ing or leaving zombie URLs in the sitemap.
• Keep internal link depth sane for the pages that matter most, so crawls concentrate where the value is.
• Render cost awareness: JavaScript-heavy pages consume budget during rendering; the server-first rendering pattern from my other guides is also a crawl-budget strategy, not only a speed strategy.

A question worth addressing directly: how often should this checklist run? My answer changed over time. Monthly felt disciplined until the month where a routing change quietly broke canonicals and stayed broken for five weeks. Weekly CI checks plus a deeper quarterly review, one where I read the rendered HTML by hand instead of trusting assertions, caught more real problems in its first cycle than the previous six automated months combined. Automation finds regressions; the quarterly human pass finds the assumptions that were wrong from the start.

Also worth saying: the cheapest version of this checklist is a pull request template. A short list of five checkboxes — canonical, description length, structured data, sitemap date, internal links — costs one minute per change and has caught more regressions on my projects than any of the elaborate tooling I once professorially recommended. Boring beats clever when the boring thing actually runs every day.

Need a technical SEO pass that finds these bugs in your build, or the whole checklist implemented properly? Book an audit — most fixes are small; the findings are not.