WordPress SEO

WordPress publishes fast and generates index bloat faster. Left at defaults it creates several URLs for every piece of content, most of which are thin, duplicative or empty, and the resulting index is mostly junk.

Almost all WordPress SEO work is subtraction.

Step 1: Permalinks

Set /%postname%/ and nothing else. Do this before publishing anything, because changing it later means redirecting every URL on the site.

Settings → Permalinks → Custom Structure → /%postname%/

Dates in URLs make content look stale and make it painful to update. Category in the URL breaks when you recategorise. If the site already uses a dated structure and has meaningful traffic, changing it is a migration with real risk — weigh it honestly rather than doing it for tidiness. See redirect-migration-plan.

Step 2: Kill the auto-generated bloat

This is where the real gains are. Every WordPress install generates these by default and almost none of them should be indexed.

Attachment pages are the single most common source of index bloat and the most overlooked. A photo-heavy site can have thousands of them. Every major SEO plugin has a one-click setting to redirect attachment URLs to the parent post — turn it on.

For tags: a tag archive with three posts is a thin page. Either curate tags down to a handful that function as real hubs with written introductions, or noindex them all. The middle position, hundreds of auto-generated tag pages, is the one that hurts.

Step 3: Pick one SEO plugin

Yoast, Rank Math and All in One SEO all do the job. The difference between them is smaller than the difference between configuring one properly and not.

Never run two. Conflicting canonical tags, duplicate meta descriptions and two sitemaps is a genuinely common and genuinely damaging problem. If migrating between them, use the built-in migration tool and then deactivate and delete the old one.

Configure, whichever you choose:

• Archive settings per the table above
• One XML sitemap, from the plugin, with the noindexed types excluded
• Title templates per post type
• Organization or Person schema, once. See schema-markup
• Breadcrumbs enabled, output in the theme

Ignore the content analysis scores. The green light for keyword density, exact-match keyphrase in the first paragraph and prescribed sentence lengths encourages worse writing. Density targets aren't a ranking factor and forcing a keyphrase into a sentence makes it read as spam to humans, which is the part that matters.

Step 4: Plugin and theme discipline

Performance and stability problems on WordPress are almost entirely plugin problems.

• Audit what's installed. Anything unused gets deactivated and deleted. Deactivated plugins still carry security risk; deleted ones don't.
• Page builders add markup weight. Elementor, Divi and WPBakery generate deep nested div structures and load substantial CSS and JS. If a builder is already in use, that's a decision made; if the site is being built now, the block editor produces far less.
• Check for shortcode residue. Removing a plugin often leaves [shortcode] text visible in published posts.
• Watch for plugins injecting their own schema, which conflicts with the SEO plugin's. Two Organization blocks with different values is worse than none.
• Related-post plugins generate large numbers of low-relevance internal links. Deliberate in-content links are worth more. See internal-linking-architecture.

Step 5: Performance

1. Object cache + page cache      (a caching plugin, or server-level)
2. A CDN in front of everything
3. Image handling: convert to WebP/AVIF, resize on upload, lazy load below fold
4. Limit plugins loading assets on every page
5. Host on something that isn't shared budget hosting

The largest single win on most WordPress sites is page caching, and the second is not serving 4 MB camera JPEGs. Both are configuration rather than engineering.

Core Web Vitals specifics are in core-web-vitals, and image handling in image-seo.

Step 6: Multilingual

WPML and Polylang both handle hreflang, and both generate a lot of URLs. Verify what's actually emitted rather than trusting the plugin:

• Reciprocal hreflang on every page in the set
• Self-referencing hreflang present
• x-default set
• Canonicals agreeing with hreflang, not fighting it

Machine-translating the whole site and publishing it is thin content in several languages at once. Translate what matters. See hreflang-international-seo.

Step 7: WooCommerce

WooCommerce inherits every WordPress problem and adds the ecommerce ones.

• Product attribute archives (/pa_color/blue/) are generated by default and are usually thin. noindex unless they're being deliberately built as landing pages.
• Filter parameters (?filter_size=10&orderby=price) generate a large URL space. Canonicalise to the unfiltered category, block the parameters if crawl budget is an issue.
• Cart, checkout and account pages should be noindex and are by default in current versions. Verify.
• Product schema comes from WooCommerce and from the SEO plugin, and both firing produces duplicates. Check the rendered output.
• Out-of-stock handling — keep the page live and indexed if it's coming back. See ecommerce-seo.

Audit checklist

# What's actually indexed vs what should be
# Run these as site: searches and compare against post/page counts

site:example.com                    # total
site:example.com inurl:tag          # tag archives — should be 0 if noindexed
site:example.com inurl:author       # author archives
site:example.com inurl:?s=          # search results — should be 0

# Verify the noindex is actually output
curl -s https://example.com/tag/something/ | grep -oP '(?<=name="robots" content=")[^"]+'

# Check for two SEO plugins fighting
curl -s https://example.com/some-post/ | grep -c 'rel="canonical"'   # must be 1

That last check catches the double-plugin problem in one line, and it's worth running on every WordPress site you touch.

Where the data comes from

WordPress makes publishing easy enough that the constraint becomes deciding what to publish, and that's the part guessing does the most damage to — a year of posts aimed at terms with no demand.

Keupera connects to WordPress directly for publishing, with the keyword research, content calendar and scoring ahead of it, so the plan and the CMS aren't separate systems. Over MCP:

claude mcp add --transport http keupera https://mcp.keupera.com/mcp -s user

If you run any automated publishing into WordPress, keep approval mode on for commercial pages, and apply an editorial bar to the queue rather than to individual drafts. A site with fifty auto-published posts nobody would read twice is a harder problem to fix than an empty blog.

Related skills

technical-seo-audit, canonical-duplicate-content, core-web-vitals, ecommerce-seo, internal-linking-architecture, hreflang-international-seo, schema-markup