WordPress SEO
A technical SEO practitioner's guide to WordPress — the default settings that hurt you, how the core sitemap and canonical handling actually work, why you run exactly one SEO plugin, and the duplicate-content sources WordPress creates on its own.
WordPress is SEO-capable, not SEO-finished. It self-canonicalizes posts since version 2.9 and ships a native XML sitemap since 5.5 — but its defaults also leave ?p=123 permalinks, attachment pages, date/tag/author archives, feeds, and internal search results all indexable, and a single Settings → Reading checkbox can silently block the whole site. The fixes that actually matter: set /%postname%/ before publishing, run exactly one SEO plugin (Yoast, Rank Math, or AIOSEO — never two, the wp_head conflict produces duplicate metadata), noindex thin archives instead of disallowing them, and keep the sitemap to canonical indexable URLs only. WordPress 6.4+ disables attachment pages on new installs by default — redirecting straight to the file, not the parent post — but existing sites keep them on and must migrate manually. Google has never said WordPress ranks better or worse than any other CMS — content and links decide that, not the platform.
TL;DR — WordPress gives you a good foundation for SEO, but it doesn’t finish the job for you. Out of the box it uses ugly
?p=123URLs, creates a bunch of thin pages you didn’t ask for, and even has a checkbox that can hide your whole site from Google. Fix the permalinks, install one SEO plugin (not two), and clean up the thin pages — that’s most of the battle.
What WordPress SEO actually means
WordPress SEO is just doing SEO on a site that happens to run on WordPress. The goal is the same as anywhere else: help search engines crawl, index, and rank your pages, and help people find them. What’s different is that WordPress has its own default settings and quirks — and a few of them quietly work against you until you change them.
WordPress runs something like 43% of the entire web, so these quirks are worth knowing.
Fix these first
A handful of defaults cause most WordPress SEO problems:
- The “Discourage search engines” checkbox. In Settings → Reading there’s a box that blocks search engines. It’s meant for sites still being built, and it gets left on and forgotten constantly. One checkbox can keep your entire site out of Google. Confirm it’s unchecked on any live site.
- Permalinks. WordPress ships with
?p=123-style URLs. Switch to Settings → Permalinks → Post name so your URLs read likeyoursite.com/your-post-title/. Do this before you publish content — changing it later means old links break unless redirects are set up. - Thin auto-generated pages. WordPress automatically creates pages for every tag, every date, every author, and even your media files (attachment pages). Most of these are thin and add no value. An SEO plugin lets you hide (“noindex”) them.
Do you need an SEO plugin?
WordPress now does some SEO on its own — it makes a sitemap and adds canonical tags. Evidence for this claim WordPress core generates XML sitemaps and outputs canonical link tags for singular content. Scope: WordPress core defaults; plugins and themes can filter or replace output. Confidence: high · Verified: WordPress: XML Sitemaps WordPress: rel_canonical But for control over meta descriptions, hiding thin pages, adding schema markup, and managing redirects, you’ll want a plugin. The popular ones are Yoast SEO, Rank Math, and All in One SEO. Any of them is fine.
The one rule that really matters: never run two SEO plugins at once. They both
try to write the same tags into your page’s <head>, and you end up with duplicate
and conflicting information that confuses search engines. Pick one. Evidence for this claim WordPress plugins can hook into wp_head and emit head markup, so overlapping SEO plugins can duplicate output. Scope: WordPress hook mechanics; exact conflicts depend on active plugins and settings. Confidence: high · Verified: WordPress: wp_head hook
The thing most people get wrong
“WordPress is bad for SEO” and “WordPress is slow” are myths — when it’s set up properly. A clean install on decent hosting with a lightweight theme and a few sensible plugins competes with anything. The problems people blame on WordPress are almost always cheap hosting, heavy page builders, too many plugins, and giant unoptimized images. Google has never said WordPress ranks better or worse than any other platform; your content and your links decide that.
Want the practitioner’s version — how the core sitemap really works, the canonical gotchas, the full duplicate-content list, and WooCommerce? Switch to the Advanced tab.
TL;DR — WordPress is SEO-capable, not SEO-finished. It self-canonicalizes singular posts since version 2.9 and ships a native XML sitemap since 5.5 — but defaults leave
?p=123permalinks, attachment pages, date/tag/author archives, feeds, and?s=search pages all indexable, and the Settings → Reading checkbox can silently block the whole site. The fixes that move the needle:/%postname%/before publishing, exactly one SEO plugin (thewp_headconflict from two is real), noindex thin archives rather than disallowing them, and a sitemap of canonical indexable URLs only. WordPress 6.4+ disables attachment pages by default on new installs — redirecting to the file itself, not the parent post; existing sites keep them enabled and migrate by hand. Google has never said WordPress is better or worse for SEO than any other CMS. Evidence for this claim WordPress added core XML sitemaps in 5.5 and attachment-page redirects for new sites in 6.4. Scope: Core version history; existing sites can retain prior attachment behavior. Confidence: high · Verified: WordPress 5.5 XML sitemaps WordPress 6.4 attachment pages
WordPress is SEO-capable, not SEO-finished
The honest framing is somewhere between the two marketing claims you usually hear. WordPress is not “SEO-friendly out of the box” in any complete sense — but it also isn’t bad for SEO. It gives you a strong, controllable foundation and then leaves a pile of indexable cruft turned on by default. The whole job is knowing which defaults to change and which auto-generated URLs to suppress.
And to be clear up front: Google has never said WordPress ranks better or worse than any other CMS. As Google’s documentation puts it, “if you’re using a CMS such as WordPress, Wix, or Blogger, it’s likely that your CMS has already made a sitemap available to search engines” — the platform is treated like any other. Rankings come from content and links, not from the logo in your admin bar. Evidence for this claim Google says common CMS platforms often generate sitemaps and does not prescribe a CMS-specific ranking advantage. Scope: Google sitemap guidance; absence of a CMS ranking advantage is an editorial inference from platform-neutral requirements. Confidence: medium · Verified: Google: Build and submit a sitemap
The defaults that hurt — and why
The “Discourage search engines from indexing this site” checkbox (Settings →
Reading) writes a site-wide noindex and a restrictive virtual robots.txt. It’s the
first thing I check on any WordPress audit, because it’s the single setting that can
silently zero out an entire site’s indexing — usually left on from staging.
The ?p=123 default permalink gives no topical signal and isn’t a clean URL.
Switch to /%postname%/ — and do it before publishing. On an established site,
changing the permalink structure means URL changes; WordPress will auto-301 the old
numeric URLs for standard post types, but custom post types and pages don’t always
redirect cleanly, so test. I’d avoid baking the category into the permalink
(/%category%/%postname%/): the day you reorganize taxonomy you trigger a mass URL
change and throw away ranking history for no proportional benefit.
Attachment pages are the WordPress-specific gotcha people forget. Every media
upload historically spawned a standalone URL containing just the file and some
auto-metadata — thin pages that can cannibalize the real ones.
WordPress 6.4 changed the default so new installs disable attachment pages
entirely — a request to one now redirects straight to the file itself, not the
parent post. Existing (upgraded) sites keep attachment pages enabled; there’s no
Settings-screen toggle for this, only wp option set wp_attachment_pages_enabled 0
via WP-CLI or editing the option directly on wp-admin/options.php. In practice
most site owners never touch that option and instead handle it the plugin way:
noindex the attachment page, or better, redirect it to the parent post via your SEO
plugin. Don’t assume an older site inherited the WordPress 6.4 default; it didn’t.
Archives, feeds, and search pages. By default WordPress generates indexable
category archives, tag archives, date archives, author archives, paginated archive
pages (?page=2), feed URLs (/feed/), attachment pages, and internal search
result pages (/page=search, i.e. ?s=). That’s the canonical list of WordPress
duplicate-content sources, and almost none of it was a decision you made.
Duplicate content WordPress creates on its own
Worth stating plainly because it surprises people: WordPress manufactures structural duplicate content by default. The recurring sources:
| Source | Example | Typical fix |
|---|---|---|
| Category archives | /category/news/ | Keep, or noindex if thin |
| Tag archives | /tag/wordpress/ | Usually noindex (thin, overlapping) |
| Author archives | /author/admin/ | Noindex on single-author sites |
| Date archives | /2023/04/ | Noindex (almost always thin) |
| Pagination | /page/2/ | Self-referential canonical (not page 1) |
| Feed URLs | /feed/ | Noindex feeds |
| Attachment pages | /photo-of-cat/ | Redirect to parent via SEO plugin (WP 6.4+ redirects new installs to the file itself instead) |
| Search results | /?s=keyword | Noindex |
The fix is almost never to panic about a penalty — Google consolidates duplicates to
a canonical rather than penalizing structural duplication. The fix is to noindex
the thin stuff and keep the sitemap clean. And a critical distinction:
noindex ≠ no-crawl. A noindexed page must stay crawlable so Google can actually
read the noindex. If you disallow it in robots.txt instead, Google can’t see the
directive — which is why you noindex thin archives rather than blocking them.
The XML sitemap: core vs. plugin
WordPress 5.5 (August 2020) added a native XML sitemap at /wp-sitemap.xml. It’s
real, but barebones. It dumps in all public post types, all public taxonomies, and
author archives — meaning it happily lists exactly the thin pages you want out of
the index. It has no image-sitemap support and limited control. So in practice most
sites use the sitemap from Yoast or Rank Math instead, which lets you include/exclude
specific post types and taxonomies and keep the file to canonical, indexable URLs.
Yoast disables the core sitemap and replaces it; that’s expected.
Two things the sitemap won’t do for you: Google ignores <priority> and
<changefreq> entirely (per Google’s own docs), and WordPress does not submit the
sitemap to Google for you — you submit it in Search Console and Bing Webmaster
Tools, and you can list it via a Sitemap: directive in robots.txt for passive
discovery. The 50,000-URL / 50MB limit from the spec still applies; split into a
sitemap index past that.
Canonical handling: core, plugin, and the conflict trap
Core has output rel=canonical via rel_canonical() since WordPress 2.9 (2009) —
singular posts and pages self-canonicalize. WordPress 4.6 didn’t add the tag; it
refactored the function to use the filterable wp_get_canonical_url(), which is
what people usually mean when they say “canonical since 4.6.” That’s a good baseline,
but core doesn’t handle
custom post types consistently across themes, doesn’t add canonicals on 404s, and
doesn’t resolve URL-variation duplicates (?utm_source=, www vs. non-www, trailing
slashes) on its own. SEO plugins replace the core output with more comprehensive
handling: custom post type canonicals, self-referential pagination canonicals
(not pointing page 2+ at page 1 — a mistake that deindexes your deeper pages),
cross-domain canonical for syndication, and per-page overrides.
Here’s the trap that ties the whole plugin question together:
the canonical tag set by your SEO plugin is the authoritative signal — but if your
theme also injects a title tag or its own SEO meta, you get a conflict. Some theme
frameworks (Genesis, Thesis) emit their own SEO tags. When you activate an SEO
plugin, disable the theme-level SEO, and inspect the rendered <head> to confirm
exactly one canonical, one title, one meta description.
One SEO plugin. Never two.
This deserves its own heading because it’s the most common self-inflicted WordPress
SEO wound. Never run two SEO plugins simultaneously. Yoast, Rank Math, and AIOSEO
all hook into wp_head() to write the title, meta description, canonical, Open
Graph/Twitter tags, robots meta, and JSON-LD. Run two and they both fire — duplicate
meta descriptions, duplicate (and contradictory) canonical tags, conflicting Open
Graph, and conflicting sitemaps. Search Console will flag the duplicate metadata.
Pick one and fully uninstall the other (deactivating leaves database entries behind).
As for which one — they all cover the core tasks; the choice is use-case and budget:
- Yoast SEO — the largest install base, the familiar traffic-light scoring, great for beginners and content teams that want a guided workflow. (WooCommerce schema is a paid add-on.)
- Rank Math — the most generous free tier: unlimited focus keywords, redirect manager, 404 monitoring, GSC + GA4 integration, and a strong schema builder (16+ types free). My pick for developers and power users.
- All in One SEO (AIOSEO) — strong WooCommerce integration, internal-link assistant, good local SEO. Suits agencies and large stores.
One caution on Yoast’s green lights: a higher Yoast score doesn’t mean better rankings. It’s a heuristic for basic on-page formatting — keyword presence, title length, readability proxies. A red-light post routinely outranks an all-green one. Content quality, intent match, authority, and links matter far more.
Schema: what WordPress does and doesn’t output
Core WordPress outputs essentially nothing useful for rich results — clean HTML Google can parse, but no JSON-LD. As Google notes, “if you use a CMS, such as Wix, WordPress, or Shopify, you might not be able to edit your HTML directly… you may be able to install a plugin that allows you to specify structured data.” That’s the path:
- Yoast auto-adds Organization/Person, WebSite (with SearchAction), WebPage, BreadcrumbList, and Article schema in JSON-LD.
- Rank Math adds those plus 16+ schema types in the free tier (FAQ, HowTo, Product, Review, Event…) and a builder for custom types.
- WooCommerce alone outputs basic Open Graph product metadata but no Product JSON-LD — you need Yoast WooCommerce SEO (paid) or Rank Math Pro for full Product schema with price, availability, and review aggregate.
WooCommerce, briefly
WooCommerce stacks more SEO surface on top of standard WordPress. The recurring
issues: the /product/ and /product-category/ URL bases (removable, with redirects
on existing sites), product variations creating near-duplicates, and — the big one —
faceted navigation generating thousands of thin filter-combination URLs. Handle
facets the same way you’d handle them anywhere: ideally JS-based filtering with no URL
change, otherwise rel=canonical to the base category and/or noindex, follow on
filter pages (with crawling allowed so the directive is seen). Shop and category
pagination wants self-referential canonicals, and Google deprecated rel=prev/next
back in 2019 — harmless if present, but don’t rely on it. Faceted nav has its own deep
treatment in the Ecommerce SEO pillar.
robots.txt and Core Web Vitals — two quick notes
WordPress serves a virtual robots.txt (it’s not a file on disk) defaulting to
disallowing /wp-admin/ while allowing admin-ajax.php. Drop a physical file at the
root and it overrides the virtual one entirely; SEO plugins let you edit the virtual
version from the dashboard. The classic mistake is disallowing /wp-content/, which
blocks CSS/JS/images and breaks rendering — don’t.
On performance: the “WordPress is slow” complaint is a configuration problem, not a
core problem. LCP issues trace mostly to TTFB (cheap shared hosting, no opcode cache)
and unoptimized hero images; INP issues to JavaScript bloat from page builders
(Elementor, Divi); CLS to images without dimensions and web fonts without
font-display: swap. Lightweight themes (GeneratePress, Kadence, Astra) plus a
caching plugin, a CDN, and modern image formats get a well-built WordPress site
through Core Web Vitals comfortably. The detail lives in the Web Performance cluster.
AI summary
A condensed take on the Advanced version:
- WordPress is SEO-capable, not SEO-finished. Strong, controllable foundation; defaults leave indexable cruft turned on. Google has never said WordPress ranks better or worse than any other CMS — content and links decide that.
- Fix-first defaults: the Settings → Reading “discourage search engines” checkbox
(can silently
noindexthe whole site);?p=123→/%postname%/before publishing; suppress thin auto-generated pages. - WordPress-made duplicate content: category/tag/date/author archives, pagination
(
?page=2), feeds (/feed/), attachment pages, and internal search (?s=//page=search). Noindex the thin ones — noindex ≠ no-crawl, so keep them crawlable rather than blocking in robots.txt. - Attachment pages: WordPress 6.4+ disables them by default on new installs, redirecting straight to the file (not the parent post); existing sites keep them enabled and must migrate manually.
- Sitemap: native since 5.5 at
/wp-sitemap.xmlbut barebones (includes thin taxonomies/authors); most sites use a plugin sitemap for control. WordPress doesn’t submit it to Google for you, and Google ignores<priority>/<changefreq>. - Canonicals: core has self-canonicalized singular posts since 2.9 (4.6 added
the filterable
wp_get_canonical_url(), not the tag itself); plugins handle CPTs, pagination, and URL variations. The plugin’s canonical is authoritative — a theme that also injects a title/meta creates a conflict. - One SEO plugin, never two: both hook
wp_headand produce duplicate/conflicting metadata. Yoast (beginners), Rank Math (best free tier), AIOSEO (agencies/Woo). - “WordPress is slow” is a myth — it’s hosting, page builders, plugin bloat, and unoptimized images, not core.
Official documentation
Primary-source guidance relevant to running SEO on WordPress.
- Build and submit a sitemap — notes that a CMS like WordPress likely already exposes a sitemap; the 50,000-URL / 50MB limits; and that Google ignores
<priority>/<changefreq>. - Intro to structured data — the “use a plugin to specify structured data” guidance for CMS users.
- Block indexing with noindex — how
noindexworks, and why a noindexed page must remain crawlable. - Site Kit is now available for all — Google’s official WordPress plugin surfacing Search Console and Analytics data in the dashboard.
Bing / Microsoft
- Submitting sitemaps to Bing — submit via Bing Webmaster Tools, or expose the sitemap through a
Sitemap:directive in robots.txt.
WordPress core
- New XML Sitemaps functionality in WordPress 5.5 — what the native
/wp-sitemap.xmlcovers. wp_headhook reference — the action SEO plugins hook to output metadata (and where two plugins collide).
Quotes from the source
On-the-record statements from Google relevant to running WordPress.
Google — sitemaps on a CMS
- “If you’re using a CMS such as WordPress, Wix, or Blogger, it’s likely that your CMS has already made a sitemap available to search engines.” — Google Search Central docs. Source
- “Include the URLs in your sitemap that you want to see in Google’s search results.” — Google Search Central docs. Source
- “Google ignores
<priority>and<changefreq>tags in XML sitemaps.” — Google Search Central docs. Source
Google — structured data on a CMS
- “If you use a CMS, such as Wix, WordPress, or Shopify, you might not be able to edit your HTML directly. Instead, your CMS may have a search engine settings page, or you may be able to install a plugin that allows you to specify structured data.” — Google Search Central docs. Source
Google — Site Kit for WordPress
- “Site Kit is Google’s official WordPress plugin — it gives you insights on how people find and use your site… with data from multiple Google tools.” — Google Search Central blog. Source
WordPress SEO setup checklist
Run this on any WordPress site, new or inherited:
- Settings → Reading: “Discourage search engines” is unchecked on the live site.
- Settings → Permalinks: set to Post name (
/%postname%/) — ideally before any content is published; if changing on a live site, verify old URLs 301. - Exactly one SEO plugin installed; any theme-level SEO meta disabled.
- Rendered
<head>inspected: exactly one title, one meta description, one canonical (no theme + plugin conflict). - Thin archives noindexed, not disallowed — tag, date, and (single-author)
author archives; internal search (
?s=); feeds as needed. - Attachment pages redirected to their parent post via your SEO plugin (don’t assume an older install inherited the WP 6.4+ default — that default only applies to new installs, and redirects to the file itself, not the parent post).
- Sitemap contains only canonical, indexable URLs (plugin sitemap, not the barebones core one, on production).
- Sitemap submitted in Google Search Console and Bing Webmaster Tools; a
Sitemap:line added to robots.txt. - robots.txt does not disallow
/wp-content/(would break rendering). - Pagination uses self-referential canonicals (not all pointing at page 1).
- WooCommerce (if present): Product schema plugin active; faceted-nav filter URLs controlled via canonical/noindex.
- Core Web Vitals checked: lightweight theme, caching plugin, optimized images, image dimensions set.
The core → theme → plugin → content framework
Assign each SEO output to one owner: WordPress core controls routing and baseline behavior; the theme renders templates; one SEO plugin owns metadata, canonicals, sitemaps, and schema; editors own page content and exceptions. Most WordPress SEO bugs are ownership conflicts. Fix the earliest owner and validate the combined public output.
WordPress SEO cheat sheet
Default settings to change first
| Setting | Default | Change to |
|---|---|---|
| Search visibility (Settings → Reading) | varies | Unchecked on live sites |
| Permalinks | ?p=123 | /%postname%/ |
| Attachment pages | standalone URLs (old installs) | Redirect to parent post |
| Thin archives (tag/date/author) | indexable | noindex (keep crawlable) |
Internal search (?s=) | indexable | noindex |
Duplicate-content sources WordPress makes on its own
- Category / tag / date / author archives
- Pagination (
?page=2) - Feed URLs (
/feed/) - Attachment pages
- Internal search results (
?s=//page=search)
SEO plugin one-liners
- Yoast — biggest install base; beginner-friendly; Woo schema is paid.
- Rank Math — best free tier; 16+ schema types; redirects + 404s free.
- AIOSEO — agency/WooCommerce-leaning; internal-link assistant.
- Rule: one plugin only — two both hook
wp_head()→ duplicate metadata.
Version facts worth remembering
- 2.9 — core canonical (
rel_canonical()); singular posts self-canonicalize. 4.6 refactored it into the filterablewp_get_canonical_url()— it didn’t add the tag. - 5.5 — native XML sitemap at
/wp-sitemap.xml(barebones). - 6.4 — attachment pages disabled by default on new installs, redirecting straight to the file itself (not the parent post); existing installs keep them on.
Gotchas
- The plugin’s canonical is authoritative — a theme injecting its own title/meta conflicts with it.
noindex≠Disallow: a blocked page can’t have itsnoindexread.- Don’t disallow
/wp-content/(breaks CSS/JS/image rendering). - A higher Yoast score ≠ better rankings.
Sample WordPress template output
Put representative posts, pages, categories, tags, authors, media, and search URLs in urls.txt:
while IFS= read -r url; do
html=$(mktemp); status=$(curl -sSL -o "$html" -w '%{http_code}' "$url")
titles=$(grep -Eio '<title>[^<]*</title>' "$html" | wc -l | tr -d ' ')
canonicals=$(grep -Eio '<link[^>]+rel=["'"']canonical["'"'][^>]*>' "$html" | wc -l | tr -d ' ')
robots=$(grep -Eio '<meta[^>]+name=["'"']robots["'"'][^>]*>' "$html" | head -1)
printf '%s\t%s\ttitles=%s\tcanonicals=%s\t%s\n' "$status" "$url" "$titles" "$canonicals" "$robots"
rm -f "$html"
done < urls.txtWordPress SEO mistakes to avoid
- Running multiple SEO plugins or schema systems with overlapping ownership.
- Changing permalink structure on a live site without a complete redirect map.
- Indexing every date, tag, author, attachment, search, and thin archive by default.
- Editing theme files directly instead of using maintainable child-theme or plugin ownership.
- Stacking cache and optimization plugins without testing their combined HTML and performance effects.
Common WordPress SEO issues
Pages contain duplicate canonicals or schema
Cause: the theme and multiple plugins emit the same element. Fix: identify one owner and disable overlapping output, then purge caches.
Search visibility disappears after launch
Cause: the production site retained the “Discourage search engines” setting, a sitewide plugin directive, or staging access rule. Fix: restore intended visibility and verify live directives across templates.
Archives or attachment URLs create duplicate inventory
Cause: default/generated routes are public without a content purpose. Fix: choose which archives deserve indexing, configure the SEO plugin consistently, and update sitemap/internal-link behavior.
Patrick's relevant free tools
- Google Index Checker — Check one URL’s observable indexability blockers, or reconcile sitemap, crawl, and supplied Search Console evidence across a URL set before verifying Google’s actual state in URL Inspection.
- Canonicalization Checker — Audit HTML and HTTP canonical signals, test the canonical target, and identify observable conflicts that can cause Google to choose a different URL.
- SEO Incident Simulator — Practice thirty deterministic technical SEO incident investigations — indexability, crawl controls, redirects, sitemaps, markup, caching, DNS, bot verification, rendering, hreflang, and faceted navigation — with clearly labeled fixture evidence and Find → Fix → Verify handoffs.
Tools for WordPress SEO
- SEO plugins (pick one): Yoast SEO, Rank Math, or All in One SEO — metadata, noindex control, sitemaps, schema, redirects.
- Google Site Kit — Google’s official plugin; Search Console + Analytics + PageSpeed data inside the WordPress dashboard.
- Google Search Console / Bing Webmaster Tools — submit your sitemap, watch indexing and duplicate-metadata warnings, inspect individual URLs.
- Caching: WP Rocket, W3 Total Cache, or LiteSpeed Cache — server-side caching to fix TTFB-driven LCP.
- Image optimization: WebP/AVIF conversion + lazy loading (most caching plugins or a dedicated image plugin) to cut LCP image weight.
- Lightweight themes: GeneratePress, Kadence, or Astra — built for Core Web Vitals rather than page-builder bloat.
- Crawler / site audit: Ahrefs Site Audit or Screaming Frog SEO Spider — surface the thin archives, attachment pages, redirect chains, and duplicate canonicals a WordPress site accumulates.
- Multilingual (if needed): Polylang, WPML, or TranslatePress for translated content and hreflang injection.
Validation tests
Test an SEO plugin or theme change
Test to run — purge caches and inspect raw output across posts, pages, archives, and special routes. Expected result — each template has one intended title, canonical, robots directive, and coherent schema graph. Failure interpretation — another owner or cached layer still conflicts. Monitoring window — immediate. Rollback trigger — revert if output disappears or duplicates across a template.
Test a permalink or migration change
Test to run — trace old URLs and crawl new internal links/sitemaps. Expected result — direct redirects reach relevant successful canonical URLs and discovery uses new routes. Failure interpretation — map or generated links are incomplete. Monitoring window — immediate technically. Rollback trigger — pause if high-value routes 404, loop, or redirect irrelevantly.
Prompts for WordPress SEO work
Classify this WordPress crawl by post, page, category, tag, author, date, attachment, search, pagination, and parameter routes. Recommend which templates should be indexed, consolidated, redirected, or excluded, and state the evidence required for each decision.
Review this plugin/theme inventory and sampled HTML. Identify which component owns titles, canonicals, robots directives, sitemaps, breadcrumbs, and schema. Flag overlaps and propose a single-owner configuration with validation and rollback steps.
Test yourself: WordPress SEO
Five quick questions on getting WordPress configured for search. Pick an answer for each, then check.
Resources worth your time
My related writing
- Canonicalization: A Beginner’s Guide — how search engines pick a canonical and consolidate signals (the backbone of WordPress duplicate-content cleanup).
- The Beginner’s Guide to PageSpeed (advanced PageSpeed guide) — the performance side, directly relevant to WordPress Core Web Vitals.
- Redirects for SEO: A Complete Guide — the redirect mechanics behind attachment-page and permalink migrations.
- The Ahrefs Site Audit Study — data on how widespread technical issues (including the duplicate-content patterns WordPress creates) really are.
My speaking
- How Search Works (SlideShare) — my crawl → render → index → serve walkthrough, the model behind every “should this WordPress page be indexed?” decision. (Standing disclaimer applies: “This is my understanding of systems… not going to be 100% complete or accurate.”)
From around the industry
- The WordPress SEO Guide (Joshua Hardwick, Ahrefs) — the practical 20-tip setup companion to this more technical treatment.
- WordPress SEO: The Definitive Guide (WPBeginner) — the comprehensive beginner checklist with the largest authority in this space.
- New XML Sitemaps Functionality in WordPress 5.5 (WordPress core team) — the primary source on what the native sitemap covers.
wp_headhook reference (WordPress Developer Resources) — the action that SEO plugins (and conflicting themes) hook to inject metadata.- WordPress SEO Myths, Busted (Search Engine Journal) — covers the “WordPress is slow / bad for SEO” myths in depth.
WordPress SEO
WordPress SEO is the process of configuring, optimizing, and maintaining a WordPress site so search engines can efficiently crawl, index, and rank it. WordPress gives you a solid foundation, but its defaults — ?p=123 permalinks, attachment pages, thin archives — need cleanup before a site is actually well-optimized.
Related: CMS, Platform SEO
WordPress SEO
WordPress SEO is the practice of configuring and maintaining a WordPress-powered site so that search engines can crawl, index, and rank its pages — and so people can find that content in organic search. WordPress powers roughly 43% of all websites, so platform-specific SEO knowledge is highly practical.
The work spans three layers: technical configuration (permalinks, sitemaps, robots.txt, canonical tags), on-page content (titles, meta descriptions, structured data), and performance (Core Web Vitals, caching, image optimization). WordPress handles some of this automatically — it self-canonicalizes singular posts since version 2.9, ships a native XML sitemap since 5.5, and redirects www/non-www — but its defaults also leave a lot indexable that shouldn’t be.
The single most important thing to understand: WordPress is SEO-capable, not SEO-finished out of the box. A default install ships ?p=123 permalinks, generates attachment pages, date archives, tag archives, author pages, feeds, and indexable internal search results — and a single “Discourage search engines” checkbox in Settings → Reading can silently block the entire site. Most sites add one (and only one) SEO plugin — Yoast, Rank Math, or All in One SEO — to control metadata, noindex thin pages, manage canonicals and redirects, and generate a leaner sitemap. Google has never said WordPress ranks better or worse than any other CMS; rankings come from content and links, not the platform.
Related: CMS, Platform SEO
Build-time retrieval analysis plus live signals for this exact article. The automatic chunk report includes a deterministic readiness score and is ready without a model download.
Search Console
sampleGA4 traffic (28d)
sampleCloudflare traffic (7d)
sampledCrUX field data (28d, phone)
sampleGoogle NLP entities
localChangelog
Updated Jul 25, 2026.
Editorial summary and recorded change details.Summary
Aligned legacy tool display names with returntag and Scout Site Audit Free.
Change details
-
Updated the linked tool names to match their current public labels.
Full comparison unavailable — no prior snapshot was archived for this revision.
Updated Jul 18, 2026.
Editorial summary and recorded change details.Summary
Corrected two version-attributed facts against WordPress core's own documentation: core canonical output dates to WordPress 2.9 (not 4.6, which only added a filterable refactor), and the WordPress 6.4 attachment-page default (not 6.4.3) redirects new-install requests to the file itself, not the parent post. Also refreshed Rank Math's free-tier schema-type count to match its current WordPress.org listing.
Change details
- Before
Since WordPress 4.6, core outputs rel=canonical via rel_canonical() — singular posts and pages self-canonicalize.AfterCore has output rel=canonical via rel_canonical() since WordPress 2.9 (2009); WordPress 4.6 only refactored it to use the filterable wp_get_canonical_url(), it didn't add the tag. - Before
WordPress 6.4.3 changed the default so new installs auto-redirect attachment URLs to the post they were uploaded to.AfterWordPress 6.4 (not 6.4.3) changed the default so new installs disable attachment pages entirely, redirecting requests straight to the file itself, not the parent post — confirmed against wordpress.org's own 6.4 release notes and the Make WordPress Core post on the change. - Before
Rank Math adds ~18 schema types in the free tier.AfterRank Math's WordPress.org plugin listing currently states 16+ schema types free, so the article now says 16+ rather than the stale ~18 figure.
Full comparison unavailable — no prior snapshot was archived for this revision.