WordPress Technical SEO Checklist: Crawling, Indexing and Performance

Most WordPress SEO advice stops at installing a plugin and filling in meta fields. The problems that actually suppress WordPress sites in search live deeper: archive duplication, redirect chains from years of edits, uncontrolled attachment pages, plugin-injected markup, and a theme that ships 800KB of unused CSS. This checklist works through the technical layer in the order that matters.

1. Crawlability

robots.txt

WordPress serves a virtual robots.txt unless a physical file exists. A sensible baseline:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

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

Do not block /wp-content/ or /wp-includes/. Blocking them prevents Google from loading CSS and JavaScript, which degrades rendering and mobile evaluation.

Crawl waste specific to WordPress

• Attachment pages. Every uploaded image can generate its own URL with no meaningful content. Redirect them to the parent post or disable them.
• Author archives on a single-author site duplicate the blog index.
• Date archives rarely serve search intent.
• Empty tag archives created by one-off tags.
• Internal search results — /?s= URLs should never be crawlable.
• Feed URLs for every taxonomy and comment thread.

2. Indexing controls

• Confirm Settings → Reading → Discourage search engines is unchecked. This flag survives staging launches more often than anyone admits.
• Index: posts, pages, curated categories, and the primary archives you actively link to.
• Noindex: internal search, thin tag archives, thank-you and confirmation pages, cart/checkout/account, and paginated comment URLs.
• Check for server-level X-Robots-Tag headers left over from staging with curl -I.

3. URL structure and permalinks

Use /%postname%/ for content sites; add a category segment only when your taxonomy is genuinely navigational and stable. Beyond the setting itself:

• Never change permalink structure on an established site without a complete redirect map.
• Keep slugs short, lowercase and hyphenated; strip stop words that add no meaning.
• Fix mixed trailing-slash behaviour — one canonical form, enforced at the server.
• Avoid dates in URLs unless the content is genuinely time-bound.

4. Redirects

WordPress sites accumulate redirects. Every edited slug adds one, and plugins add their own layer on top of server rules. Three rules keep this manageable:

1. One hop only. Crawl your own site and flatten every chain to a direct 301.
2. Server level where possible. Nginx or Apache rules execute before PHP loads; a redirect plugin boots WordPress first.
3. No internal links to redirected URLs. Update the link, do not rely on the redirect.

5. Canonicals

WordPress outputs self-referencing canonicals by default, and SEO plugins override them. Things to verify:

• Paginated archives self-canonicalise (page 2 canonicals to page 2, not page 1).
• Parameter URLs from filters or tracking canonicalise to the clean URL.
• WooCommerce variation URLs canonicalise to the parent product.
• No page canonicalises to the homepage unless it genuinely is the homepage.

6. XML sitemaps

Whether you use core sitemaps or a plugin, the sitemap should contain only indexable, canonical, 200-status URLs. Exclude anything you have set to noindex — a URL that appears in the sitemap and carries a noindex tag sends contradictory signals. Keep lastmod accurate; a sitemap that reports every URL as modified today is ignored as a freshness signal.

7. Structured data

Most WordPress sites end up with duplicated or conflicting schema because the theme, the SEO plugin and a review plugin each output their own graph. Validate with the Rich Results Test and pick a single source of truth. Useful types:

• Organization or Person sitewide, with consistent sameAs profiles.
• Article or BlogPosting on posts, with real author and date values.
• BreadcrumbList matching the visible breadcrumb trail.
• FAQPage only where visible FAQ content exists on the page.
• Product and Offer on WooCommerce products, with accurate availability and price.

8. Internal linking

WordPress makes it easy to publish and hard to link. Practical structure:

• A pillar page per major topic, linked from navigation.
• Supporting posts linking up to the pillar with descriptive anchor text.
• The pillar linking down to each supporting post.
• Related-post blocks driven by taxonomy, not by random selection.
• No orphan posts — every published URL reachable within three clicks of the homepage.

9. Performance and Core Web Vitals

Technical SEO and performance overlap heavily on WordPress because the same causes — bloated themes, plugin asset stacking, unoptimised images, no caching layer — drive both crawl inefficiency and poor field data. The implementation detail is covered in how to fix Core Web Vitals in WordPress. The short version:

• Page caching plus object caching, and a CDN in front.
• Serve WebP/AVIF, size images correctly, lazy-load everything below the fold.
• Dequeue plugin CSS and JS on pages where the plugin is not used.
• Preload the LCP image; never lazy-load it.
• Reserve space for ads, embeds and dynamic banners to prevent layout shift.

10. WooCommerce-specific checks

• Noindex cart, checkout, account and order-received pages.
• Handle out-of-stock products deliberately: keep the page with alternatives, or 301 when discontinued.
• Control faceted navigation — filters should not generate thousands of crawlable parameter URLs.
• Enable HPOS for order-table performance on larger stores.
• Keep product schema in sync with actual stock and price.

11. Monitoring

1. Search Console Page indexing report reviewed monthly at pattern level.
2. Crawl stats watched for response-time spikes after plugin updates.
3. Scheduled crawl with alerts for new 404s, redirect chains and noindex changes.
4. Field CWV data from the Core Web Vitals report, not lab scores alone.
5. Uptime and TTFB monitoring — hosting is a ranking input through crawl rate and user experience.