Technical SEO Checklist: The System We Run Before Every Launch

A technical SEO checklist is a structured set of audits and fixes that ensure search engines can crawl, render, index, and rank your site without friction. The best checklists are tied to tooling, prioritised by impact, and shaped by the failure modes you've actually seen in production—not theoretical best practice.

This is the system we run before every launch at Streamline Digital, built from 25+ years of watching sites go live with broken canonicals, misconfigured CDNs, and JavaScript that renders fine locally but fails in Googlebot. It's opinionated, tool-specific, and designed to catch the expensive mistakes before they compound.

If you need a technical audit or remediation work, Technical SEO covers the full stack.

Why Most Technical SEO Checklists Miss the Point

Most checklists are either too generic (tick "fix broken links") or too exhaustive (127 line items, half of which don't apply to your stack). The useful ones are short, prioritised by revenue impact, and tied to specific tooling you can run repeatedly.

We've seen three common failure modes:

• Checklist theatre: teams tick boxes without understanding why a canonical matters or what a crawl budget actually controls.
• Over-optimisation: fixing every Lighthouse suggestion while ignoring the fact that Googlebot can't render your category pages because your CDN blocks its user agent.
• No regression testing: site launches clean, then a Shopify app injects 14,000 parameterised URLs and crawl budget collapses.

The checklist below is structured around systems—crawling, rendering, indexing, performance, schema—and every item includes the tooling we use and the failure mode it prevents.

Crawl Budget and Site Architecture

Crawl budget is the number of URLs Googlebot will request from your site in a given period. For most sites under 10,000 pages, it's not a constraint. For Shopify Plus retailers with 50,000+ product variants, faceted navigation, or poorly configured apps, it's the difference between your new collection ranking in week one or week six.

What we check:

• Robots.txt: confirm it's not blocking CSS, JS, or critical API endpoints. We've seen Shopify themes that block /apps/ and break all embedded functionality in Google's render.
• XML sitemaps: validate structure, confirm last-modified dates are accurate, check that priority and changefreq aren't set to meaningless defaults. We strip out-of-stock or discontinued SKUs from the sitemap entirely.
• Parameterised URLs: audit query strings (?sort=, ?filter=, ?page=) and confirm they're canonicalised or blocked. Screaming Frog + Google Search Console's URL Parameters tool.
• Orphan pages: pages with no internal links. We export internal link graphs from Screaming Frog and cross-reference against Analytics to find high-traffic orphans.

Tooling: Screaming Frog (crawl + internal link analysis), Google Search Console (crawl stats, URL parameters), curl -I for header checks.

Failure mode prevented: Googlebot wastes 60% of its crawl budget on parameterised filter URLs, new product pages sit in "Discovered – currently not indexed" for weeks.

Rendering and JavaScript Indexability

If your site is built on React, Next.js, or a headless Shopify stack, rendering is not optional. Googlebot uses a Chromium-based renderer, but it's not Chrome—it's slower, it doesn't execute all polyfills, and it won't wait indefinitely for your client-side fetch to resolve.

What we check:

• Server-side rendering (SSR) vs client-side rendering (CSR): we curl a product page and confirm critical content (H1, price, description) is present in the raw HTML. If it's not, Googlebot may not index it reliably.
• Fetch-as-Google: use Google Search Console's URL Inspection tool to see exactly what Googlebot renders. Compare it to the live page. We've caught missing breadcrumbs, broken schema, and entire sections that don't render because of a CDN race condition.
• JavaScript errors in Googlebot: check the JavaScript console in the rendered HTML view. A single unhandled promise rejection can stop rendering mid-page.
• Lazy loading: confirm images and content below the fold aren't indefinitely deferred. Intersection Observer is fine, but we've seen implementations that never fire because Googlebot doesn't scroll.

Tooling: curl, Google Search Console (URL Inspection, "View Crawled Page"), Puppeteer for local rendering tests, Cloudflare Workers logs for CDN behaviour.

Failure mode prevented: product pages render perfectly in Chrome but return empty <body> tags to Googlebot because the CDN strips the Accept-Encoding header.

Core Web Vitals and Performance

Core Web Vitals—Largest Contentful Paint (LCP), Interaction to Next Paint (INP), Cumulative Layout Shift (CLS)—are confirmed ranking factors and directly affect conversion rate. A 1-second delay in LCP typically costs 5–10% in bounce rate for ecommerce.

What we check:

• LCP < 2.5s: measure on real devices (Chrome User Experience Report data in Search Console). If hero images are the LCP element, we preload them and serve WebP/AVIF via Shopify's CDN or Cloudflare Polish.
• INP < 200ms: audit third-party scripts (Facebook Pixel, Klaviyo, chat widgets). We defer or async everything non-critical and use Partytown to run scripts in a web worker when possible.
• CLS < 0.1: reserve space for images (width/height attributes), avoid injecting content above the fold post-render, confirm font swaps don't cause reflow. We've seen Shopify apps inject banners that shift the entire page 300px down.
• Server response time (TTFB): target < 600ms. For Shopify, this means auditing app middleware, optimising Liquid loops, and confirming the CDN is configured correctly (cache hit rate > 85%).

Tooling: Lighthouse CI (automated regression testing), WebPageTest (real-world throttling), Chrome DevTools (Performance panel), Search Console (Core Web Vitals report), Cloudflare Analytics.

Failure mode prevented: site launches with LCP of 4.2s because the hero image is a 3MB PNG loaded from a non-CDN origin, mobile conversions drop 18% week-on-week.

Indexing and Canonicalisation

Canonicals tell Google which version of a URL to index when duplicates exist. Misconfigured canonicals are the most common technical SEO mistake we see—self-referencing canonicals that point to the wrong domain, or missing entirely.

What we check:

• Self-referencing canonicals: every page should have a <link rel="canonical"> pointing to itself (or the preferred version). We audit this in Screaming Frog and confirm there are no chains (A → B → C).
• HTTPS and www/non-www consistency: confirm canonical, internal links, and sitemaps all use the same protocol and subdomain. We've seen sites with canonicals pointing to http:// while the sitemap uses https://www..
• Pagination: rel="next" and rel="prev" are deprecated, so we either canonicalise paginated pages to a View All page (if it's performant) or let each page self-canonicalise and rely on internal linking.
• International and hreflang: if you have multiple country or language versions, confirm hreflang tags are reciprocal and include an x-default. We validate this with Merkle's hreflang testing tool.

Tooling: Screaming Frog (canonical audit), curl -I (header inspection), Google Search Console (coverage report, duplicate content warnings).

Failure mode prevented: Shopify site has 12,000 product pages, all with canonicals pointing to the US store instead of the UK store, UK traffic collapses post-migration.

Schema Markup and Structured Data

Schema markup (JSON-LD) helps Google understand entities—products, reviews, breadcrumbs, FAQs, organisations. It's also the only reliable way to get rich results (star ratings, price, availability) in SERPs.

What we check:

• Product schema: validate offers, aggregateRating, brand, sku, availability. Confirm prices match the on-page price and currency is set correctly.
• Breadcrumb schema: every page below the homepage should have breadcrumb JSON-LD. We've seen Shopify themes that output breadcrumbs in the HTML but not in schema.
• Organisation and LocalBusiness schema: homepage should include logo, contact info, social profiles. For local businesses (Bournemouth, Dorset), we add address, geo, openingHours.
• Review schema: confirm reviews are marked up with reviewRating and author. Avoid fake or incentivised reviews—Google's guidelines are strict and penalties are manual.

Tooling: Google's Rich Results Test, Schema.org validator, Merkle Schema Markup Generator, manual JSON-LD inspection in DevTools.

Failure mode prevented: product pages have reviews visible on-page but no schema markup, so star ratings never appear in Google Shopping or organic results, CTR is 30% lower than competitors.

Security, Redirects, and Status Codes

This is the unglamorous plumbing—HTTPS, redirects, 404s, server errors—but it's where most launches break.

What we check:

• HTTPS everywhere: confirm SSL certificate is valid, no mixed content warnings, HSTS header is set. We check this with SSL Labs and Screaming Frog.
• Redirect chains and loops: audit all 301s and 302s, confirm no chains longer than one hop (A → B is fine, A → B → C is not). We export redirects from Screaming Frog and visualise them in a spreadsheet.
• 404 vs 410: soft-404s (200 status on a "not found" page) confuse Google. We confirm out-of-stock products return 404 or 410, or canonicalise to a parent category if the product will return.
• Server errors (5xx): monitor uptime and error rates in Cloudflare or your CDN. A spike in 503s during a traffic surge will tank rankings faster than any on-page issue.

Tooling: Screaming Frog (status code audit), SSL Labs, Cloudflare Analytics, curl -I, Google Search Console (coverage errors).

Failure mode prevented: site migration includes 4,000 redirects, 30% of them are chained (old URL → interim URL → new URL), crawl budget is wasted, rankings drop for two months.

Ongoing Monitoring and Regression Testing

A checklist is only useful if it's repeatable. We run a subset of these checks weekly (automated Lighthouse CI, Search Console API pulls) and the full audit quarterly or after any major deploy.

What we automate:

• Lighthouse CI: runs on every Shopify theme deployment, fails the build if LCP > 3s or CLS > 0.15.
• Search Console API: pulls coverage errors, Core Web Vitals, and crawl stats into a Postgres database, alerts via n8n if errors spike.
• Screaming Frog scheduled crawls: weekly crawl of the sitemap, exports to CSV, diffed against the previous week to catch new 404s or canonicalisation drift.

If you're launching a new site, migrating platforms, or fixing a traffic drop, book a free discovery call and we'll walk through the checklist that applies to your stack.

FAQ

How long does a technical SEO audit take?

For a typical Shopify site (5,000–20,000 URLs), expect 2–3 days for the initial crawl, analysis, and prioritised fix list. Larger sites or custom headless builds can take a week. Remediation depends on the severity—simple canonical fixes might be a few hours, a full rendering overhaul could be 3–4 weeks.

Can I run this checklist myself or do I need an agency?

You can run most of it with Screaming Frog (£149/year) and Google Search Console (free). The hard part is interpreting the data and prioritising fixes—knowing whether to fix canonicals before Core Web Vitals, or whether your crawl budget issue is actually an indexing issue. If you're technical and have time, start with the crawl budget and indexing sections.

What's the difference between technical SEO and on-page SEO?

Technical SEO is about making sure Google can crawl, render, and index your site—crawl budget, rendering, canonicals, performance, schema. On-page SEO is about what's in the content—titles, headings, keyword targeting, internal linking strategy. You need both, but technical issues will kill rankings faster than weak meta descriptions.

How often should I re-run a technical SEO checklist?

Full audit: quarterly or after any major deploy (platform migration, theme change, new app installs). Automated monitoring (Lighthouse CI, Search Console API, scheduled crawls): weekly. If you're in a competitive niche or running heavy traffic (Black Friday, seasonal peaks), increase the frequency—crawl budget and performance can degrade quickly under load.