WordPress SEO: Fixing the Technical Defaults That Cost You Rankings

A fresh WordPress install publishes one post at up to five URLs: the post itself, its category archive, one or more tag archives, the author archive, and — historically — an attachment page per uploaded image. Most WordPress SEO work is deciding which of those archives should be indexed, which should carry noindex, and making sure the theme's permalink and canonical setup is not fragmenting authority. The defaults are built for browsing, not for search, and they need auditing.

Archive duplication: category, tag, and author pages

WordPress auto-generates an archive listing for every category, every tag, and every author. These pages repeat the same post excerpts in different groupings, which produces overlapping, thin listings that compete with each other and with the posts themselves.

The decision is per-archive, not global:

• Categories usually earn their place — they map to real topics and can rank as hub pages if you give them unique introductory copy. Keep them indexable and add content above the post list.
• Tags are typically the problem. Sites accumulate hundreds of one-post or two-post tags, each generating a near-empty archive. These are thin by definition. noindex the tag archives (keep them crawlable so Google reads the directive) or stop using tags for narrow terms.
• Author archives are pure duplication on a single-author blog — the author page lists the same posts as the blog index. noindex them unless you run a genuine multi-author site where author pages carry E-E-A-T value.
• Date archives (/2026/07/) are almost never useful for search; disable or noindex them.

Crawlinx flags overlapping listing pages as duplicate.content, near-empty archives as content.thin, and pages that are mostly navigation with little unique body text as content.low_ratio. The noindex directive itself, once you apply it, shows as index.noindex — expected on archives you deliberately excluded, but worth confirming it is not on pages you meant to keep.

Attachment pages

When you upload an image, WordPress creates a standalone "attachment page" — a URL that displays that single image with almost no content. On an image-heavy site this generates hundreds of thin, indexable pages that dilute crawl attention. Modern WordPress and most SEO plugins redirect attachment URLs back to the parent post or the file itself, but many older sites still have them live and indexed. Audit for them and redirect attachment URLs to the parent post. They surface in Crawlinx as content.thin.

Default permalinks

Out of the box WordPress uses a query-string permalink: ?p=123. These are non-descriptive, expose an internal ID, and pile parameters onto every URL — Crawlinx flags them as url.many_params. Switch to a descriptive structure (Settings → Permalinks → Post name gives /post-title/) before you have any inbound links, because changing it later forces a wave of redirects.

One trap when you do migrate: changing permalinks or moving from ?p= to pretty URLs can create redirect chains if the rewrite rules stack — old URL → intermediate → final. Keep redirects to a single hop. Crawlinx flags multi-hop redirects as redirect.chain.

Pagination

WordPress paginates the blog index, category archives, and long posts (/page/2/, or <!--nextpage--> splitting one post across URLs). rel="next"/"prev" is deprecated and Google no longer uses it. Each paginated URL should carry a self-referencing canonical to itself, not to page 1 — the pages hold different posts and are not duplicates. Do not let a plugin canonicalize the whole series back to the first page, and make sure deep paginated pages are still reachable by a crawlable <a href> link, or the posts on them can become orphaned (links.orphan).

Canonical and noindex handling

WordPress core does not emit rel="canonical" on every page type consistently; SEO plugins add self-referencing canonicals and expose per-page indexing controls. Whichever tool you use, the platform-independent rules apply: every indexable page needs a self-referencing canonical pointing at a live 200 URL, and a canonical target must not itself carry noindex. A missing canonical shows as canonical.missing.

Framed generically — because the trap repeats across every SEO plugin — the two failures to audit for are a plugin silently overriding a canonical you set manually, and conflicting directives where one setting says index and another says noindex. Google resolves conflicting robots directives to the most restrictive, so an accidental noindex wins. Verify what actually ships in the rendered <head>, not what the plugin dashboard claims.

Heavy themes and Core Web Vitals

Multipurpose WordPress themes and page builders ship large CSS and JavaScript bundles, render-blocking scripts, and layout that shifts as assets load. That drives up server response time and hurts the Core Web Vitals Google measures from real-user field data. Crawlinx flags a slow server response as perf.slow_response; response time is the part of loading performance a crawl can measure directly.

The platform-specific levers: choose a lean theme over a maximalist multipurpose one, use page caching and object caching, and reserve dimensions for images to prevent layout shift. Our Core Web Vitals guide covers the metrics and thresholds; the WordPress angle is that theme and plugin weight is usually the root cause, not your content.

A note on plugins

Framed generically, so it holds regardless of which plugin you run: SEO and caching plugins are the most common source of self-inflicted WordPress problems. Two plugins both emitting canonicals or sitemaps produce conflicts. A caching plugin can serve stale noindex directives or cache a logged-in view. A "broken link" or redirect plugin can accumulate chains over time. Audit the rendered output, not the settings pages — the crawl sees what actually ships.

Takeaway

WordPress SEO is mostly archive and default cleanup: decide category-by-category which archives to index, noindex thin tag and author pages, redirect attachment pages, switch off ?p= permalinks early, and keep pagination self-canonical and crawlable. Then confirm your theme is not the reason your Core Web Vitals fail. Run the technical SEO audit checklist against a live install to see which defaults are still costing you.