The Technical SEO Checklist We Use on Every Site (In the Order That Matters)

Why order matters more than the number of checks

Search engines process a site in a pipeline, so a technical SEO checklist should follow the same pipeline. Google has to discover a URL, crawl it, render it, decide whether to index it, understand what it is about, and only then weigh how good the experience is. A break at any step stops everything after it.

We see the cost of getting this wrong every month. An owner spends weeks shaving half a second off load time while the staging site's noindex tag is still live on production. The speed work was real. It just could not matter until the page was allowed into the index.

The rest of this guide walks each stage with the specific checks we run during a technical SEO audit.

The 15-minute technical SEO checklist

Before a full audit, run these six checks. They take about 15 minutes, need only a browser and Google Search Console, and catch the issues that cause the biggest traffic losses we see.

1. Search site:yourdomain.com in Google. Compare the rough count to how many real pages you have. Far fewer means an indexing problem; far more means duplicates or junk URLs.
2. Open /robots.txt. Look for Disallow: / or rules that block folders holding real pages.
3. View source on your home page and top service page. Search for noindex and check the rel="canonical" points to the page itself.
4. Open Search Console's Pages report. Read the reasons listed under "Why pages aren't indexed" and note any that affect pages you care about.
5. Test four URL versions: http, https, www and non-www. All should land on one version with a single redirect.
6. Load your top page on your phone over cellular. If you are waiting, so is your customer.

If any of the six fail, stop and fix it before working through the rest of this technical SEO checklist. These are the problems that make every other improvement invisible.

Stage 1 and 2: Discovery and crawling checks

Discovery and crawling checks confirm that every page you want found is linked, listed in a sitemap and allowed to be fetched, and that pages return the right status code. This is where the most damaging, and most fixable, problems live.

Discovery

• An XML sitemap exists, lists only canonical, indexable URLs that return 200, and is submitted in Search Console.
• Sitemaps stay under 50,000 URLs and 50MB uncompressed each; larger sites use a sitemap index.
• Every important page is reachable through normal HTML links, ideally within three clicks of the home page.
• No orphan pages: pages in the sitemap that no other page links to.

Crawling

• robots.txt does not block pages, CSS or JavaScript you need rendered.
• Search and AI crawlers you want, including Googlebot, Bingbot and OAI-SearchBot, are not blocked by a firewall, CDN rule or security plugin.
• Real pages return 200. Removed pages return 404 or 410, or 301 to a true replacement.
• Redirects are one hop. No chains (A to B to C) and no loops.
• No soft 404s: thin "not found" pages that return 200.
• Parameter and filter URLs are controlled so crawlers do not spend time on thousands of near-duplicates.

One rule people get wrong constantly. Google's own robots.txt documentation says it "is not a mechanism for keeping a web page out of Google." A blocked URL can still be indexed if other pages link to it. To keep a page out, use noindex, and leave it crawlable so Google can see the tag.

Stage 3 and 4: Rendering and indexing checks

Rendering and indexing checks confirm that your main content exists in the page Google builds, and that the version Google indexes is the one you chose. A page can be crawled perfectly and still be indexed wrong, or not at all.

Rendering

• Main text, headings and links appear in the raw HTML or in the rendered page shown by Search Console's URL Inspection tool.
• Navigation links are real <a href> elements, not click handlers on buttons.
• Content behind tabs or accordions is in the HTML on load, not fetched only on click.
• Mobile and desktop show the same content. Google indexes the mobile version, so anything missing on mobile is missing in search.

Indexing

• No stray noindex on pages that should rank. Check templates, not just pages.
• Each indexable page has a self-referencing canonical, and duplicates point to the primary version.
• Canonicals, redirects, internal links and the sitemap all agree on the same URL.
• Thin, duplicate or auto-generated pages (tag archives, empty categories, internal search results) are noindexed or removed.
• Pagination and faceted URLs are either indexable with unique value or kept out.

Canonicals are not commands. Google's guide to consolidating duplicate URLs describes redirects and rel=canonical as strong signals and sitemap inclusion as a weak one, and Google weighs them with everything else. When your signals disagree, Google picks for you.

Stage 5: Helping search engines understand the page

Understanding checks make sure structure, internal links and structured data tell search engines and AI systems exactly what each page is, who it is for and how it relates to the rest of the site. This is the stage that has grown most with AI search.

• One H1 per page that states the topic. H2s and H3s form a logical outline, not a design device.
• Unique title tag and meta description on every indexable page, with the main topic near the start of the title.
• Internal links use descriptive anchor text and connect each service page to its related locations, guides and case studies.
• Structured data in JSON-LD for the organization, local business details, services, articles, breadcrumbs and FAQs where they genuinely apply.
• Structured data matches visible content. Markup that describes things a visitor cannot see is a liability.
• Images have descriptive alt text, sensible file names and explicit width and height.
• Business name, address and phone are identical across the site.
• Hreflang, if you serve multiple languages or regions, is reciprocal and points to indexable URLs.

AI engines lean on this stage heavily because they quote pages, not whole sites. Our guides on how to rank in ChatGPT and what llms.txt is go deeper on making pages machine-readable without gimmicks.

Stage 6: Speed and page experience checks

Page experience checks confirm the site loads fast, responds quickly and stays visually stable for real visitors on real phones. Google's Core Web Vitals are the shared yardstick, and they are measured on field data, not a single lab test.

Those thresholds come from Google's Web Vitals guidance on web.dev, which recommends judging them at the 75th percentile of page loads, split by mobile and desktop. Our Core Web Vitals guide covers the fixes in detail.

Beyond the three metrics

• HTTPS everywhere, with no mixed content warnings.
• No intrusive pop-ups covering content on mobile.
• Tap targets large enough and text readable without zooming.
• Unused plugins, scripts and tracking tags removed, not just disabled.

This is a big reason we hand-code our websites instead of using page builders. Our web development team starts with almost nothing to remove, which makes the speed checklist short.

Stage 7: Measurement checks

Measurement checks confirm you will notice when something breaks and can tie organic visits to real leads. Without them, a technical problem can quietly cost you months of traffic before anyone looks.

• Search Console is verified as a domain property, so every subdomain and protocol is covered, and email alerts reach someone who reads them.
• GA4 is installed on every template and fires once per page, not twice.
• Calls, forms and bookings are tracked as key events, with click-to-call and text links included.
• An uptime monitor checks the home page and one deep template every few minutes.
• Every deploy, plugin update and theme change is logged with a date, so a traffic drop can be matched to its cause.
• A baseline export (indexed pages, top queries, Core Web Vitals) is saved before any big change.

That is the full 40-check list across seven stages. The stages are not equal: a single failure in stages 1 to 4 can outweigh every item in stages 5 to 7 combined. Our analytics and reporting team owns this stage on every account we run.

How to prioritize what you find

Prioritize by multiplying impact by reach. A full technical SEO checklist will surface dozens of issues, and fixing them in the order you found them wastes weeks. We score each one on two 1-to-3 scales and work from the highest product down.

A sitewide noindex scores 9 and gets fixed today. Missing alt text on one blog image scores 1 and goes on the backlog. An unminified script on every page might score 4 and slot in after the indexing work.

Fix templates, not pages

Almost every high-reach issue lives in a template, a theme setting or a plugin. Find the source and fix it once. When we built Nusbaum Medical Centers, a site with 3,066 pages live, this was the only workable approach. Fixing pages one at a time at that scale is not a plan.

Your monthly technical SEO checklist

Technical SEO is maintenance, not a one-time project, because every plugin update, new page and redesign can break something. After the initial audit, a short monthly technical SEO checklist catches problems before they cost traffic.

We run these checks inside UnifiedIQ, our own platform, which scores every page for SEO so a broken template shows up as a drop across many pages at once, and checks client sites every minute, with SSL expiry warnings, so our team hears about an outage before customers do. That is how we kept all 50 SEO landing pages for Joe Sale Photography scoring 99 to 100.

Site migrations: the checklist inside the checklist

A redesign, platform change or domain move is the single riskiest moment for technical SEO, because every URL, template and setting changes at once. Run this list before and after launch.

1. Crawl the old site and export every URL that has traffic, links or rankings.
2. Map each old URL to its closest new URL. Redirect one to one, not everything to the home page.
3. Carry over titles, meta descriptions, headings and structured data for pages that perform.
4. On launch day, confirm the staging noindex and robots.txt block are gone from production.
5. Submit the new sitemap and inspect the top 20 URLs in Search Console.
6. Check analytics and call tracking are firing on every key template.
7. Recrawl at day 1, day 7 and day 30. Fix any redirect that lands on a 404.

If you are planning a rebuild, bring SEO into the plan before design starts. It is cheaper to build it right than to repair rankings afterward. Our SEO team and search group join every website project at the strategy stage for this reason. If you want our team to run the full checklist on your site and hand you a scored fix list, get in touch. For a broader starting point, read our guide to SEO for small business.

Technical SEO checklist questions, answered