Free Resource

Technical SEO Checklist

42 items across 7 categories: crawling and indexing, speed, mobile and rendering, URLs, structured data, security, and international and headless sites. Platform-agnostic, with WordPress notes where they help.

Technical SEO Checklist with items being worked through and checked off across seven categories

How to use this checklist

Work in section order. It follows how Google handles a page: crawl, index, render, then everything else. A faster LCP does nothing for a page robots.txt blocks.

For each item, start with the Search Console report under Check, because it shows what Google actually saw. Then confirm single URLs with the free tools, before and after the fix.

Run the list monthly if you publish weekly, quarterly on quieter sites, and right after a migration or a domain, HTTPS, CMS, theme or CDN change. WordPress settings, plugins, themes and content are on the WordPress SEO checklist.

New site or established site: where to start

New site

Before launch, remove staging’s noindex and robots.txt blocks, settle on one HTTPS host and submit the sitemap.

Then set speed budgets for each template while there are few of them. Core Web Vitals field data needs real traffic before it appears.

Established site

Start in Search Console: Page indexing, Crawl stats and Core Web Vitals. Fix whatever blocks pages that earn traffic first, then redirects and canonicals, then speed.

Change one thing at a time, so you can tell what moved.

Crawlability and Indexing

Can Google reach your pages, and are the right ones indexed? Open Search Console → Indexing → Pages before anything else.

Blocked URLs can’t be crawled, and blocked scripts can break how Google renders a page.

Check: Search Console → Settings → robots.txt, and the robots.txt validator for single URLs.

Fix: Remove rules matching pages or assets you want seen. To keep a page out of results, use noindex: Google ignores noindex in robots.txt.

Robots.txt validator →WordPress robots.txt →

Redirects, noindexed pages and 404s in a sitemap blur which URLs you want indexed.

Check: Search Console → Indexing → Sitemaps, then the sitemap checker for errors and noindexed URLs.

Fix: Generate it from your CMS or SEO plugin, keep lastmod accurate, and add a Sitemap line to robots.txt. Google ignores priority and changefreq.

Sitemap checker →

A stray noindex removes a page from results, and an X-Robots-Tag header doesn’t show in the page source.

Check: Indexing → Pages → “Excluded by ‘noindex’ tag”, and the indexability checker for one URL.

Fix: Remove it at the source: SEO plugin, theme, server or CDN rule. Google may skip rendering a page whose HTML says noindex, so JavaScript can’t undo it.

Indexability checker →Noindex explained →

Filters, sorts and calendars can generate endless URLs. Google says crawl budget mainly matters on large sites.

Check: Search Console → Settings → Crawl stats: look for parameter URLs among the examples.

Fix: Disallow those patterns in robots.txt. Noindex doesn’t save crawling, because Google has to fetch a page to see it.

Server errors, timeouts or a firewall blocking Googlebot slow crawling, and repeated failures drop pages.

Check: Crawl stats → Host status: robots.txt fetch, DNS and server connectivity.

Fix: Ask your host about 5xx and 429 responses, and allow verified Googlebot through bot protection.

Discovered means Google hasn’t crawled the page yet; crawled means it chose not to index it.

Check: Indexing → Pages, both reasons, with URL Inspection on a few samples.

Fix: Improve or merge thin pages, link to the ones that matter, and stop generating the ones that don’t.

The fix, step by step →

A missing page that returns 200, or redirects to an unrelated page such as the homepage, can be treated as a soft 404, which Google reports and drops.

Check: Indexing → Pages → Soft 404 and Not found (404). The indexability checker shows status codes.

Fix: Serve a real 404 or 410 for removed pages, or 301 them to a true replacement.

Fixing 404s →

Site Speed and Core Web Vitals

Core Web Vitals are measured on real Chrome users at the 75th percentile. Fix the templates with the most traffic first. WordPress caching and image settings are in the WordPress checklist.

Largest Contentful Paint times how long the main image or text block takes to appear.

Check: Search Console → Experience → Core Web Vitals. PageSpeed Insights names the LCP element.

Fix: Speed up server response, serve the LCP image from your own domain at the size shown, and give it fetchpriority="high".

Cumulative Layout Shift measures content jumping as the page loads, which causes mis-taps.

Check: PageSpeed Insights lists the elements that shift.

Fix: Set width and height on images, embeds and ads, reserve space for banners, and use fallback fonts sized like your web font.

Interaction to Next Paint, which replaced FID in March 2024, measures how fast the page responds to taps, clicks and keys.

Check: Field data in Search Console and PageSpeed Insights. A lab page-load test such as Lighthouse can’t measure it; Total Blocking Time is the proxy.

Fix: Remove or delay third-party scripts, break up long JavaScript tasks, and keep event handlers small.

A 3,000px photo displayed at 800px wastes bandwidth on every phone.

Check: PageSpeed Insights flags oversized and legacy-format images.

Fix: Serve WebP or AVIF with srcset and sizes, so each screen downloads a file that fits.

Lazy-loading waits until an image is needed; on the main image that delays LCP.

Check: Inspect the LCP element PageSpeed Insights names. It shouldn’t carry loading="lazy".

Fix: Lazy-load below-the-fold images and iframes only. Recent WordPress versions do this, but sliders and builders can override it.

Every other metric waits for the first byte. Google’s web.dev guidance rates a Time to First Byte of 0.8 seconds or less as good.

Check: PageSpeed Insights shows TTFB in its field data.

Fix: Cache full pages at the server or CDN, give static files long cache lifetimes, and leave overloaded hosting.

The browser can’t paint until blocking files in the head have loaded.

Check: PageSpeed Insights lists render-blocking requests.

Fix: Inline the CSS needed above the fold, load the rest later, and defer scripts that first paint doesn’t need.

Mobile and Rendering

Google indexes the mobile version of every page and renders its JavaScript. Check what it actually sees.

Since July 2024 Google crawls every site with its smartphone crawler, so content missing on mobile isn’t indexed.

Check: URL Inspection → Test live URL → View tested page, compared with desktop.

Fix: Reflow content on small screens instead of dropping it. Tabs and accordions are fine.

Google retired its Mobile-Friendly Test and Mobile Usability report in December 2023, but small text and cramped tap targets still lose readers.

Check: Chrome DevTools → Lighthouse in mobile mode, or the device toolbar.

Fix: Fix flagged font sizes and tap targets in the theme’s CSS.

Content that loads only after a click, or links without an href, may never be seen.

Check: URL Inspection → View tested page → HTML: search for key text and links.

Fix: Put core content in the server HTML and use real links with an href, not click handlers.

Google’s page experience guidance names pop-ups that cover the main content on arrival.

Check: Open key pages on a phone from a search result.

Fix: Use banners that take a small part of the screen. Legally required notices, such as cookie consent, are fine.

Without it, phones show the desktop layout shrunk down.

Check: View source for name="viewport" with content="width=device-width, initial-scale=1".

Fix: Add it to the theme head, without maximum-scale=1, so users can still zoom.

URL Structure and Architecture

Every page should have one URL, one canonical and a short path from the homepage.

A canonical is a hint Google weighs with redirects, links and sitemaps. When they conflict, Google picks for you.

Check: The canonical checker per URL, and Indexing → Pages for “Google chose different canonical than user”.

Fix: Use absolute URLs to the 200, indexable version, and link internally to that same URL.

Canonical checker →Canonical statuses →

http and https, www and non-www, with and without a trailing slash: each is a separate URL to Google.

Check: Run each variant of your homepage through the redirect checker.

Fix: Pick one, 301 the rest to it in one hop at server or CDN level, and use it in canonicals and sitemaps.

Redirect checker →

Uppercase, session IDs and tracking parameters create duplicate URLs and are harder to share.

Check: Export your URLs with the sitemap URL extractor and scan for them.

Fix: Use hyphenated words, keep tracking parameters out of internal links, and 301 any URL you change.

Sitemap URL extractor →

Each hop adds a round trip for users and crawlers, and Googlebot gives up after ten.

Check: The redirect checker shows every hop of a URL.

Fix: Point each old URL straight at the final one, and update internal links so they need no redirect.

Bulk redirect checks →

A page with no internal links is hard for Google to find and gets no share of your site’s link value.

Check: Compare your sitemap with a crawl from the internal link checker. URLs only in the sitemap are orphans.

Fix: Link to them from relevant, well-linked pages, or remove the ones that no longer matter.

Internal link checker →

Deeply buried pages get crawled less often and look less important.

Check: A desktop crawler’s crawl depth column. Screaming Frog’s free version handles 500 URLs.

Fix: Link priority pages from navigation, hub pages and categories, and keep pagination short.

Structured Data

Markup describes the page so Google can show rich results; it gives no ranking boost by itself. Plugin settings for each type are in the WordPress checklist.

Only supported types earn rich results. As of October 2026 they include Product, Article, BreadcrumbList, Organization, LocalBusiness, Recipe and Video.

Check: The search gallery in Google’s structured data documentation.

Fix: Map each template to one main type. Drop HowTo (deprecated 2023) and FAQ (no rich results since May 7, 2026) as goals.

Missing required properties make a page ineligible. Product snippets need name plus one of offers, review or aggregateRating.

Check: Rich Results Test: errors mean ineligible, warnings mean optional data is missing.

Fix: Fill required fields from real page data, then the recommended ones you have, such as Article author and dates.

Product schema generator →Article schema generator →

A theme, plugin and app each adding Product or Organization markup produces duplicates that can conflict.

Check: Rich Results Test: count the items detected of each type.

Fix: Turn off every source but one, usually the SEO plugin.

Markup about content users can’t see breaks Google’s structured data policies and can lead to a manual action.

Check: Compare prices, ratings, dates and questions in the markup with the visible page.

Fix: Generate markup from the same data that renders the page, never hard-coded.

Markup added by JavaScript or a tag manager only exists after rendering.

Check: Rich Results Test on the live URL; the Schema Markup Validator for types Google doesn’t use.

Fix: Fix errors first, then warnings, and re-test after deploys.

One template change can break markup on thousands of pages at once.

Check: The rich result reports in Search Console, such as Breadcrumbs, Product snippets and Merchant listings.

Fix: Fix the template, then click Validate fix in the report.

Security and Site Health

HTTPS is a lightweight ranking signal and a trust signal for visitors. Hacked pages and broken links cost far more.

An expired certificate puts a full-page warning in front of every visitor.

Check: Your browser’s certificate details show the expiry date and the hostnames covered.

Fix: Use your host’s or CDN’s free automatic certificates, covering both www and non-www.

HTTP images or scripts on an HTTPS page trigger browser warnings or get blocked.

Check: Chrome DevTools → Console flags mixed content.

Fix: Update hard-coded http:// URLs. On WordPress, back up, then run a database search-replace with WP-CLI or a plugin.

The Strict-Transport-Security header makes browsers skip the insecure first request.

Check: DevTools → Network → the page’s response headers.

Fix: Start with a short max-age, then raise it to a year. Add includeSubDomains or preload only when every subdomain serves HTTPS.

Links to 404s waste crawls and strand visitors.

Check: The broken link checker, and Indexing → Pages → Not found (404).

Fix: Edit each link at its source. Add a redirect only when outside sites link to the old URL.

Broken link checker →

Hacked sites get spam pages injected, browser warnings and lost rankings.

Check: Search Console → Security & Manual actions, plus a site:yourdomain.com search for pages you didn’t publish.

Fix: Clean the site, close the hole (often an outdated plugin), then request a review in the report.

Alt text, descriptive link text and real headings help screen readers and search engines read the same page.

Check: The alt text checker, and Lighthouse’s accessibility audit for contrast and focus.

Fix: Fix contrast and focus styles in the theme. Per-post alt text is in the WordPress checklist.

Alt text checker →

International and Headless CMS Considerations

Skip this section if you run one language on a traditional CMS.

It sends searchers to their version. Annotations must be reciprocal and include the page itself, or Google ignores them.

Check: View source on each version. Search Console no longer reports hreflang errors.

Fix: Use valid codes, such as en-GB rather than en-UK, in the head, HTTP headers or sitemap, and keep each version self-canonical.

x-default names the fallback page. Redirecting by IP can hide versions from Googlebot, which mostly crawls from the US.

Check: Look for hreflang="x-default", and load each version over a VPN.

Fix: Point x-default at a language picker or main version, and suggest other versions with a banner.

Indexed staging copies duplicate your site and leak unreleased pages.

Check: Search site: for staging hostnames and preview parameters.

Fix: Put staging behind a password. On WordPress, check staging’s “Discourage search engines” setting doesn’t travel to live.

A client-only app sends an empty shell, so indexing waits for rendering, and missing pages show as soft 404s.

Check: View source, not the inspector: titles, content and links should be in the HTML.

Fix: Use server-side rendering or static generation for indexable routes, and return real 404 status codes.

A sitemap rebuilt on a schedule lists deleted pages and misses new ones.

Check: Compare the sitemap with your CMS’s published list using the sitemap URL extractor.

Fix: Rebuild it from a publish webhook, with lastmod from each entry’s real update time.

Worked example: a technical audit after a redesign

A composite of a typical case, not a client: a 900-page software site in English and German moved to a new WordPress theme and from www to the bare domain. Two weeks later, impressions were falling and not-indexed pages rising. The audit found six problems.

  1. robots.txt still blocked /wp-content/plugins/, which held the page builder’s scripts. URL Inspection screenshots showed half-empty pages.
  2. German pages carried canonicals to their English versions.
  3. hreflang still listed the old www URLs.
  4. http://www took two hops to reach the new host, and internal links and the sitemap still used www.
  5. The homepage hero image was lazy-loaded, pushing mobile LCP past the 2.5-second line.
  6. Organization markup appeared twice, from theme and plugin.

They were fixed in that order. The robots.txt rule broke rendering on every page, so it went first. The canonicals and hreflang told Google to drop the German half of the site. Redirects and internal links came next, checked with the redirect checker, and the sitemap was regenerated. The hero image and the duplicate markup waited, because speed and schema only matter once the right pages are indexed. Each fix was confirmed with URL Inspection’s live test before the next began.

What this checklist does not cover

  • WordPress settings, plugins, themes and content: see the WordPress SEO checklist.
  • On-page copy: titles, descriptions, headings and keywords.
  • Backlinks and other off-site signals.
  • Full WCAG accessibility audits and server hardening.
  • Migration planning. Use this list to check a migration’s result, not to plan one.

Frequently asked questions

What is the difference between technical and on-page SEO?

Technical SEO is whether search engines can crawl, render and index your pages, and how fast and secure they are. On-page SEO is what the page says: titles, headings, copy and links. Technical problems stop good pages being found; on-page problems stop found pages ranking or being clicked.

Which items matter most?

Anything that blocks crawling or indexing of pages you want found: a robots.txt rule, a stray noindex, a wrong canonical, server errors. Those make every other fix pointless for the pages affected. After that, prioritize by how much traffic an item touches.

Do Core Web Vitals affect rankings?

They are part of the page experience signals Google uses, but its documentation says relevance comes first. Treat them as a tiebreaker and a user experience issue, not a ranking lever.

Does a small site need an XML sitemap?

Google says a small, well-linked site may not need one. It still helps: the Page indexing report can filter to submitted URLs, which shows quickly when something you care about drops out. SEO plugins generate one for free.

Is structured data still worth it now that FAQ rich results are gone?

Yes, for the types Google still supports, such as Product, Article, BreadcrumbList, Organization and LocalBusiness. Google stopped showing FAQ rich results on May 7, 2026 and deprecated HowTo in 2023, so don’t add those for rich results.

Do I need a paid crawler?

No. Search Console, PageSpeed Insights, Chrome DevTools, the Rich Results Test and the free tools linked above cover every item. A desktop crawler helps once a site passes a few hundred pages; Screaming Frog’s free version crawls up to 500 URLs.

Get the WordPress fixes drafted for you

On a WordPress site connected through its free plugin, RankHive reads your Search Console data and drafts fixes for the items here that WordPress can change: redirects, robots.txt, schema, alt text and internal links. You approve each one before the plugin writes it.

Find my SEO fixes

Nothing changes on your site until you say yes.