The Ultimate Technical SEO Checklist (2026)

Technical SEO is the foundation of any successful SEO strategy. Without a solid technical base, even the best content will not rank well, because search engines simply cannot find, crawl, render, or trust it. This checklist covers every technical aspect you need to address in 2026, broken into clear sections you can work through one at a time.

Think of technical SEO as the plumbing of your website. Visitors never see it, but when it breaks, everything downstream suffers. The good news is that most technical issues are fixable once you know where to look. Use this guide as a working audit document: run a scan with DarnItSEO's site audit, then walk through each section below and tick off the checks as you confirm them. For an overview of how all of this fits together, see our guide to what SEO actually is.

How to Use This Checklist

Technical SEO has a natural order. Search engines must first discover your URLs (crawlability), then decide whether to store them (indexability), then render and rank them based on quality and experience signals. Working in that order saves time, because there is no point optimizing Core Web Vitals on a page that is accidentally blocked by robots.txt. Below, the sections follow that funnel: crawlability first, then indexability, canonicalization, redirects, HTTPS and security, performance, mobile, structured data, internationalization, and finally log file analysis for advanced sites.

1. Crawlability

Crawlability is whether search engine bots can reach your pages at all. If Googlebot cannot fetch a URL, nothing else in this checklist matters for that page.

• robots.txt — Ensure your robots.txt file exists at the root domain and does not accidentally block important pages or critical assets like CSS and JavaScript. A single stray Disallow: / can deindex an entire site. Verify your rules with our robots.txt tester and read the full robots.txt guide for syntax details.
• XML Sitemap — Submit a comprehensive sitemap to Google Search Console and Bing Webmaster Tools. Keep each sitemap file under 50,000 URLs and 50 MB uncompressed; use a sitemap index file to group multiple sitemaps for larger sites. Generate one quickly with our sitemap generator.
• Crawl budget — For large sites (50,000+ URLs), optimize crawl budget by blocking low-value URL patterns (faceted filters, sort parameters, internal search results) and fixing crawl traps such as infinite calendar links or session IDs in URLs.
• Internal linking — Ensure every important page is reachable within three clicks from the homepage. Orphan pages (pages with no internal links pointing to them) are rarely crawled and almost never rank.
• Server response codes — Confirm that live pages return 200, removed pages return 404 or 410, and you are not serving soft 404s (a 200 status on a page that says "not found"). Soft 404s waste crawl budget and confuse indexing.
• Render-blocking resources — Do not disallow the CSS and JS that Google needs to render your page. Google renders pages with a headless Chromium; if it cannot load your layout files, it may see a broken or empty page.

Example robots.txt

A clean robots.txt for a typical content site looks like this. Notice that it allows everything by default, blocks only genuinely private or low-value paths, and points crawlers to the sitemap:

User-agent: *
Allow: /
Disallow: /admin/
Disallow: /cart/
Disallow: /search?
Disallow: /*?sessionid=

# AI crawlers - allow or block per your policy
User-agent: GPTBot
Allow: /

Sitemap: https://example.com/sitemap_index.xml

2. Indexability

Crawlability gets a bot to your page; indexability decides whether the page is stored in the search index and eligible to rank. Many sites lose traffic not because of bad content but because pages are silently kept out of the index.

• Meta robots — Use noindex only on pages you genuinely do not want indexed (admin pages, thank-you pages, thin filter combinations, staging environments). Audit your codebase for accidental site-wide noindex tags, which are a common cause of sudden traffic loss after a deploy.
• X-Robots-Tag — Remember that indexing directives can also live in HTTP headers, not just the HTML. Check both. A page can look fine in the markup but carry an X-Robots-Tag: noindex header from the server.
• Canonical URLs — Set rel="canonical" on every page to consolidate duplicate or near-duplicate content. Self-referencing canonicals are fine and recommended. Verify your canonicals with our canonical checker.
• Pagination — Google ignores rel="next" and rel="prev" for indexing, so ensure paginated pages contain crawlable links to the next page and that each paginated URL self-canonicalizes (do not canonicalize page 2 to page 1).
• Index coverage report — Review the Pages report in Google Search Console regularly. Watch for spikes in "Crawled - currently not indexed" or "Discovered - currently not indexed", which usually signal quality, duplication, or crawl-budget problems.
• Parameter handling — Decide deliberately how URL parameters are treated. Tracking parameters, filters, and sort orders can create thousands of duplicate URLs that dilute crawl budget and split ranking signals.

3. Canonicalization and Duplicate Content

Duplicate content rarely triggers a manual penalty, but it confuses search engines about which version to rank and splits link equity across versions. Canonicalization is how you tell Google which URL is the "real" one.

• One URL per piece of content — A single page should not be reachable at multiple URLs with the same content (with and without trailing slash, with and without parameters, HTTP and HTTPS, www and non-www). Pick one canonical form and enforce it.
• Cross-domain canonicals — If you syndicate content, use a canonical tag pointing back to the original source so the original gets the ranking credit.
• Avoid conflicting signals — Do not let your canonical tag, sitemap, internal links, and redirects disagree. If the canonical says one URL but every internal link points to another, Google may ignore your canonical entirely.
• Mobile and AMP parity — If you run separate mobile or AMP versions, ensure canonical and alternate tags reference each other correctly.

4. Redirects and URL Structure

Redirects are essential during migrations and restructures, but they are also a common source of crawl waste and lost link equity when handled carelessly.

• Use 301 for permanent moves — A 301 (permanent) redirect passes ranking signals to the destination. Use 302 (temporary) only when the move really is temporary.
• Eliminate redirect chains — A chain (URL A to B to C) wastes crawl budget and dilutes signals. Always redirect directly to the final destination. Find and fix chains with our redirect chain checker.
• Avoid redirect loops — Loops make a page completely inaccessible. They often appear from misconfigured HTTPS or trailing-slash rules.
• URL structure — Keep URLs short, descriptive, and lowercase. Use hyphens, not underscores, to separate words. Avoid deep nesting and unnecessary folders.
• WWW and trailing-slash consistency — Choose either www or non-www, and decide whether URLs end in a slash. Redirect every other variant to your chosen canonical form so you do not split signals.

5. HTTPS, TLS, and Security Headers

HTTPS has been a confirmed Google ranking signal since 2014, and a secure connection is now table stakes. Beyond the ranking nudge, browsers actively warn users away from insecure pages, which destroys trust and click-through.

• Valid TLS certificate — Every page must be served over HTTPS with a certificate that is current, issued by a trusted authority, and matches the domain. Check expiry and chain validity with our SSL checker.
• Redirect HTTP to HTTPS — All HTTP URLs should 301-redirect to their HTTPS equivalents so no insecure version remains accessible.
• No mixed content — Ensure no page loads images, scripts, or stylesheets over HTTP on an HTTPS page. Mixed content triggers browser warnings and can block resources. Scan for it with our mixed content checker.
• Security headers — Configure the headers below. Verify what your server is actually sending with our HTTP header checker.

• HSTS — Strict-Transport-Security with a max-age of at least one year forces secure connections and removes redirect latency for returning visitors.
• CSP — Content-Security-Policy restricts which resources the browser may load, preventing cross-site scripting.
• X-Content-Type-Options — Set to nosniff to stop MIME-sniffing.
• X-Frame-Options — Set to DENY or SAMEORIGIN to prevent clickjacking.
• Referrer-Policy — Set to strict-origin-when-cross-origin.
• Permissions-Policy — Restrict access to sensitive browser APIs like camera, microphone, and geolocation.

6. Core Web Vitals and Performance

Core Web Vitals are part of Google's page experience signals and measure real-world loading, interactivity, and visual stability. They are a tiebreaker between pages of similar relevance, and a poor experience can suppress an otherwise strong page.

• Largest Contentful Paint (LCP) — Target 2.5 seconds or less. Usually driven by the hero image, web fonts, or a slow server response.
• Interaction to Next Paint (INP) — Target 200 milliseconds or less. INP replaced First Input Delay in 2024 and measures responsiveness across the whole visit, not just the first click. Heavy JavaScript is the usual culprit.
• Cumulative Layout Shift (CLS) — Target 0.1 or less. Reserve space for images, ads, and embeds so content does not jump around as the page loads.
• Image optimization — Serve modern formats (WebP, AVIF), use responsive srcset images, and lazy-load offscreen images.
• JavaScript and CSS — Minify, tree-shake, defer non-critical scripts, and inline critical CSS. Reducing main-thread work directly improves INP.
• Compression and caching — Enable Brotli or Gzip and set sensible Cache-Control headers for static assets.

Measure your scores with our Core Web Vitals checker and page speed test, and read the full Core Web Vitals guide for fixes. Use field data (real users) over lab data when judging whether you pass.

The three thresholds at a glance

7. Mobile-First Indexing

Google indexes the mobile version of your site by default. If your mobile experience hides content, blocks resources, or is hard to use, your rankings suffer everywhere, including on desktop.

• Viewport meta tag — Include <meta name="viewport" content="width=device-width, initial-scale=1"> so pages scale correctly.
• Content parity — The mobile version must contain the same primary content, headings, structured data, and links as desktop. Hiding content behind tabs is fine; removing it from mobile is not.
• Touch targets — Buttons and links should be at least 48x48 pixels with adequate spacing so they are easy to tap.
• Font sizes — Use a minimum of 16px for body text to avoid forcing users to pinch-zoom.
• No horizontal scrolling — Content must fit within the viewport width on common phone sizes.

For a deeper treatment, see our mobile SEO optimization guide.

8. Structured Data

Structured data (schema markup) helps search engines understand your content and unlocks rich results such as star ratings, FAQs, and breadcrumbs. It is increasingly important for AI search, where engines rely on explicit machine-readable signals.

• JSON-LD format — Always prefer JSON-LD over Microdata or RDFa. It is easier to maintain and Google's recommended format.
• Organization schema — Add to your homepage with logo, social profiles, and contact info to support brand knowledge panels.
• Article schema — Add to blog posts with author, datePublished, and dateModified.
• Breadcrumb schema — Helps Google understand and display your site hierarchy in results.
• FAQ and HowTo schema — Add where genuinely relevant; eligibility for rich results has narrowed, so use them honestly.
• Validate everything — Test your markup with our schema markup tester and explore implementation patterns on our schema tools page. Markup with errors can be ignored entirely.

Structured data also feeds answer engines. If you care about being cited by AI assistants, review your answer engine optimization setup alongside your schema, and track how often your brand appears with our visibility tracker.

9. International SEO and Hreflang

If you serve multiple languages or regions, hreflang annotations tell Google which version to show to which audience. Misconfigured hreflang is one of the most common and costly technical mistakes on international sites.

• Return tags must be reciprocal — If page A points to page B as its German alternate, page B must point back to A. Non-reciprocal hreflang is ignored.
• Use correct codes — Use ISO 639-1 language codes and optional ISO 3166-1 Alpha-2 region codes (for example en, en-gb, es-mx). Region codes are optional, but invalid codes break the cluster.
• Include a self-reference — Each page in a language cluster should include an hreflang entry pointing to itself.
• Add an x-default — Provide an x-default for users whose language or region you do not explicitly target.
• Pick one method — Implement hreflang in the HTML head, in HTTP headers, or in the sitemap, but do not mix conflicting methods. Generate correct tags with our hreflang generator.

10. Sitemaps Done Right

A sitemap is a roadmap that helps search engines discover and prioritize your URLs. It does not guarantee indexing, but it speeds up discovery, especially for new or deep pages.

• Include only canonical, indexable URLs — Do not list redirected, noindexed, or canonicalized-away URLs. Every URL in the sitemap should return 200 and be the canonical version.
• Keep lastmod accurate — An honest <lastmod> date helps crawlers prioritize changed pages. Faking it across the whole site erodes trust in the signal.
• Split large sitemaps — Stay under 50,000 URLs and 50 MB per file, and use a sitemap index to combine them.
• Reference it in robots.txt — Add a Sitemap: line so crawlers find it even before you submit it manually.
• Validate before submitting — Check structure and URL health with our sitemap validator.

Example sitemap snippet

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2026-05-01</lastmod>
  </url>
  <url>
    <loc>https://example.com/blog/technical-seo-checklist</loc>
    <lastmod>2026-05-12</lastmod>
  </url>
</urlset>

11. Log File Analysis for Large Sites

For sites beyond a few thousand pages, server log files are the single most accurate source of truth about how search engines actually crawl you. Reports in Search Console are sampled and delayed; raw logs are not.

• Confirm real bot activity — Verify that requests claiming to be Googlebot resolve to genuine Google IP ranges, then measure how often each section of your site is crawled.
• Find crawl waste — Logs reveal bots spending budget on parameter URLs, redirect chains, or 404s instead of money pages. Fixing this redirects crawl budget to pages that matter.
• Spot orphan and stale pages — Pages that bots rarely or never hit are candidates for better internal linking or removal.
• Track status codes over time — A rising share of 5xx errors in the logs is an early warning of server or capacity problems that can tank crawling.

Running Your Audit

Use DarnItSEO's site audit to check all of these factors in a single scan. The tool analyzes your site's technical health across every category listed here and provides prioritized, actionable recommendations, then surfaces them in your dashboard so you can track progress over time. You can also use the dedicated robots.txt tester, sitemap validator, and SSL checker for targeted checks. If you manage multiple sites or want ongoing monitoring, compare plans on our pricing page.

Frequently Asked Questions

How often should I run a technical SEO audit?

Run a full technical audit at least once a quarter, and always after a major change such as a site migration, redesign, CMS switch, or framework upgrade. For active sites, set up continuous monitoring so regressions (a stray noindex, a broken canonical, an expired certificate) are caught within days rather than discovered months later when traffic has already fallen.

What is the difference between crawlability and indexability?

Crawlability is whether a search engine bot can reach and read a page. Indexability is whether, after crawling it, the engine is allowed and willing to store that page in its index so it can rank. A page can be crawlable but not indexable (for example, it carries a noindex tag), and fixing one does not automatically fix the other. You generally solve crawlability first, then indexability.

Do security headers directly improve my rankings?

Most security headers do not directly move rankings, with the notable exception of HTTPS, which is a confirmed lightweight ranking signal. The bigger value is indirect: HTTPS and a clean security posture prevent browser warnings, build user trust, protect against content-altering attacks, and keep your page experience signals healthy. See our dedicated guide on security headers and SEO for the full picture.

How many URLs can a single sitemap contain?

A single XML sitemap file can hold up to 50,000 URLs and must not exceed 50 MB uncompressed. If you have more URLs than that, split them across multiple sitemap files and reference all of them from a sitemap index file. List only canonical, indexable, 200-status URLs to keep the signal clean.

Should I block AI crawlers in robots.txt?

That is a business decision, not a one-size-fits-all rule. Blocking crawlers like GPTBot or CCBot can protect proprietary content, but it also removes you from the data those engines use to cite sources, which can reduce your visibility in AI search. If being referenced by AI assistants matters to you, allow the crawlers and focus on answer engine optimization instead. Whatever you decide, set it explicitly so the behavior is intentional.

Why are my pages crawled but not indexed?

"Crawled - currently not indexed" usually points to a quality or duplication problem: the content is thin, too similar to other pages, or not seen as adding unique value. It can also reflect crawl-budget triage on very large sites. Improve the depth and uniqueness of the content, strengthen internal links to the page, remove near-duplicates, and make sure the page is not competing with a stronger canonical elsewhere on your site.

Does JavaScript hurt my technical SEO?

JavaScript does not inherently hurt SEO, but heavy client-side rendering can slow down indexing and damage INP. Google renders JavaScript, but rendering is resource-intensive and can be delayed. Where possible, server-render or statically generate critical content so it is in the initial HTML, defer non-essential scripts, and confirm with the URL Inspection tool that Google sees your fully rendered content. Lean JavaScript also directly helps your Core Web Vitals.