A Technical SEO Checklist That Actually Ships

Every technical SEO problem is a failure at one of four stages: the crawler could not reach the page, could not render it, could not understand it, or decided not to index it. Work out which stage is failing and the fix is usually obvious. Skip that step and you are guessing.

This is the checklist we run on a site before touching content, ordered by what blocks the most. The first seven decide whether you rank at all. The rest decide how well.

Stage 1 — Can it be crawled?

Nothing else matters until this is true. These are binary: they either pass or your pages are invisible.

• robots.txt does not block what you want ranked. Fetch yoursite.com/robots.txt and read it. A stray Disallow: / from a staging config is the single most expensive character sequence in SEO.
• The site returns 200 for real pages and 404 for missing ones. Soft 404s — a "not found" message served with a 200 status — get pages indexed as thin content. Check with curl, not a browser.
• No redirect chains longer than one hop. Each hop loses a little and costs crawl budget. A chain of four usually means four migrations nobody cleaned up.
• An XML sitemap exists, is listed in robots.txt, and contains only indexable URLs. Sitemaps full of redirects and 404s teach Google to distrust the file.
• Internal links reach every page you care about. A page linked from nowhere is discoverable only through the sitemap, which is a weaker signal than a link.

Stage 2 — Can it be rendered?

Google renders JavaScript, but rendering is queued and expensive, and anything that fails silently stays missing.

• The main content is in the initial HTML. Run curl on the URL and search for a sentence from the middle of your page. If it is not there, your content depends on client-side rendering and you are accepting a delay and a risk.
• Critical resources are not blocked. If CSS or JS needed for layout is disallowed in robots.txt, Google renders a broken page and judges it accordingly.
• Links are real anchors. A div with an onClick handler is not a link and will not be followed. This one quietly orphans entire sections.

Stage 3 — Can it be understood?

• One H1 per page, describing that page. Not the company name on every page.
• Heading hierarchy descends without skipping. H2 under H1, H3 under H2. Headings are structure, not font sizes.
• Title tag is 50–60 characters and unique across the site. Duplicate titles across pages are a strong signal that the pages are duplicates.
• Meta description is 150–160 characters. It is not a ranking factor and it is absolutely a click-through factor.
• Canonical tag is present and self-referencing unless the page genuinely is a duplicate. A canonical pointing at the homepage from every page is a classic template bug that de-indexes a whole site.
• Structured data validates. Organization and WebSite sitewide; BreadcrumbList on anything nested; Article on posts; Product or SoftwareApplication where they apply. Test in the Rich Results Test, and note that an incomplete block — an Offer with no price, say — reports as an error rather than a partial win.
• Images have descriptive alt text. Describe the image, not the keyword you wish you ranked for.
• hreflang is consistent and reciprocal if you serve more than one region. Declaring a variant that does not exist is worse than declaring none.

Stage 4 — Will it be indexed and ranked?

• No accidental noindex. Check the meta robots tag and the X-Robots-Tag header — the header is invisible in page source and catches people out.
• Core Web Vitals pass on field data, not lab data. LCP under 2.5s, INP under 200ms, CLS under 0.1. Lab scores from a fast laptop are not the measurement Google uses; the Chrome UX Report is.
• The page works on a mid-range Android on a slow connection. That is the device most of your Indian traffic is on. Test on it rather than on the phone in your pocket.
• HTTPS everywhere, with no mixed content. One http image on an https page throws a warning in the console and a doubt in the browser.
• Thin and duplicate pages are consolidated. Twenty location pages that differ only by the city name are a quality liability, not twenty chances to rank.

What to do in what order

Technical SEO has a dependency order, and working out of order wastes effort. Fixing Core Web Vitals on a noindexed page achieves nothing.

1. Unblock. robots.txt, noindex tags, canonical errors. Days, not weeks, and the highest return of anything on this list.
2. Make it readable. Server-render the content, fix the heading structure, write real titles and descriptions.
3. Make it understandable. Structured data, internal links, breadcrumbs.
4. Make it fast. Core Web Vitals, image formats, render-blocking resources.
5. Then stop. Technical SEO has a floor to reach and sharply diminishing returns above it. Once the floor is sound, the constraint is content and links, and further technical tuning is displacement activity.

Catching regressions

Most technical SEO damage is not gradual — it arrives in a deployment. A staging noindex that shipped, a template change that dropped the canonical, a migration that added a redirect chain. The defence is a baseline: record the title, description, canonical, robots directive and schema for your top pages, and compare after each release. It turns a problem you find in a quarterly audit into one you find the same afternoon.