A technical SEO checklist for developers

01SEO bugs are just bugs

A page the crawler can't reach is a 404 for your biggest visitor. A canonical tag pointing at the staging server is a bug. Content that only appears after a client-side framework boots is, from the crawler's chair, missing content. I own SEO across a large commercial web estate at my day job, and the most useful reframe I've found for getting developers to care is this: technical SEO is debugging for one very patient, very literal user named Googlebot.

What follows is the technical SEO checklist I actually work from, five layers in dependency order: crawl, render, speed, semantics, structured data. This site runs a 200-item version of the same program against every build, so none of it is theory. If you're the marketing lead writing the tickets, the table below is your ticket structure. If you're the developer receiving them, the rest of this note is the acceptance criteria.

02The technical SEO checklist, layer by layer

Every audit I run walks the same five layers in the same order, because each depends on the one before it. Fast pages that can't be crawled rank exactly as well as slow ones, which is to say not at all.

Crawl and indexing comes first because crawlability gates everything: the crawler has to fetch the page and be allowed to keep it. Check that robots.txt blocks what you meant to block and nothing else, that no template carries a leftover noindex, that the sitemap lists only URLs that return 200, and that redirects resolve in one hop. Then check the two tags that settle most indexing arguments:

<!-- one true URL: absolute, and pointing at production -->
<link rel="canonical" href="https://example.com/blog/post/">

<!-- what the crawler may do with this URL -->
<meta name="robots" content="index, follow, max-image-preview:large">

Canonical tags answer "which URL is the real one" when several serve the same content: trailing slash and not, http and https, tracking parameters. The robots meta answers "may this URL be indexed at all." Get either of those wrong and every fix downstream is decoration.

Rendering is where modern frontend stacks quietly lose. Google runs JavaScript, but rendering is deferred to a second pass (opens in a new tab), so content that only exists after your bundle executes gets seen late, inconsistently, or not at all. My rule: anything that needs to rank ships in the server HTML. Hydrate for interactivity all you want after that. That's half the reason this site is static Eleventy output; the static-site field note walks through that decision.

Speed is a ranking input with published pass marks: Google's Core Web Vitals thresholds (opens in a new tab) are LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1, measured on real-user field data. The Core Web Vitals guide covers how to hit those numbers, and the performance ROI note covers why the business should care beyond rank.

Semantic HTML is the cheapest layer to get right. One h1 per page. Heading levels that nest without skipping. Links that are real <a href> elements, because the crawler follows hrefs and will not click your divs. Alt text on images that carry meaning, landmarks so the document has a machine-readable shape. The crawler reads the same DOM a screen reader does, which is why the accessibility work and the SEO work keep paying each other's bills.

Structured data is the one layer that adds capability instead of fixing defects: JSON-LD describes the page in schema.org vocabulary, and it's what makes rich results possible. The rule that keeps you out of trouble is to describe only what's visible on the page. A minimal article looks like this:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "A technical SEO checklist for developers",
  "datePublished": "2026-07-17",
  "author": { "@type": "Person", "name": "Adam Culpepper" }
}
</script>

03The mistakes I keep finding in audits

Different stacks, different teams, same bugs. After enough audits the list stopped surprising me; these five account for most of what I find:

• The launch noindex that never left. A staging safeguard graduates to production inside a base template, and the site spends its first quarter politely asking Google to ignore it. Grep for noindex the day you launch, then again a week later.
• Canonical tags that point somewhere else. At the staging domain, at http instead of https, or (my personal favorite) every page canonicalized to the homepage, which tells Google the site has exactly one page worth keeping.
• Redirect chains. http to https to www to the trailing-slash version is four fetches to deliver one page. Every internal link should point at the final URL, and every redirect should land in one hop.
• Soft 404s. An empty search or category page that says "nothing found" over a 200 status looks, to the crawler, like a thin page you chose to publish. If there's nothing there, say so with a real 404 or 410.
• Structured data drift. The markup claims review stars the redesign removed two years ago. Markup that doesn't match the visible page violates Google's guidelines and can cost you every rich result on the site, so treat "matches the page" as a compliance rule, not a style preference.

Here is the same checklist in a form you can work through. The layers are numbered because the order matters: each one depends on the one before it, so a failure high up makes everything below it unmeasurable. It remembers what you tick, so an audit can span a few sittings.

04Proving your work

A fix nobody can verify is indistinguishable from a fix that never shipped, so every item on the checklist names its proof. Most of the proof comes from the same free instrument, and collecting it takes minutes.

Search Console settles arguments. URL Inspection shows the exact HTML Google rendered, which ends most "is our JavaScript content indexed" debates with one screenshot. The page indexing report shows a fix rolling through the index over the following weeks, and the Core Web Vitals report shows field data, the numbers that count for ranking, rather than whatever your laptop's Lighthouse run said.

The Rich Results Test (opens in a new tab) validates structured data the way Google will read it, which catches both syntax errors and eligibility problems before they reach production.

My habit, and the one I push on every team I work with: the passing test goes in the ticket. It turns SEO work from "trust me" into evidence, and it builds the paper trail that makes the next budget conversation easier.

05When to call in help

Most of this is hygiene a team can own. Run this technical SEO checklist quarterly and after every redesign, because redesigns are where canonicals and redirects go to die, and keep the proof in the tickets.

One caveat if your customers all live within a few miles of you. Everything above is a floor, and a floor does not generate local demand on its own: that job belongs to your Google Business Profile and the signals around it, which I covered in the local SEO note. The two get confused constantly, so there is also a short piece on which of the two is actually your problem.

The exceptions are architectural. Content locked behind client-side rendering, a migration that has to map thousands of URLs without dropping equity, template surgery across a legacy estate: those are projects, not tickets. That kind of work is the frontend development I take on, and an audit against this exact list is usually where I start. Either way, crawl before you assume. The bugs are almost never where the ticket says they are.

FN-18 · End of sheet