WordPress SEO: What to Actually Configure (and What to Leave Alone) in 2026

WordPress SEO is not fixed by installing a plugin: it is fixed by knowing what core already does on its own, what it leaves open, and what does not depend on the CMS at all. This guide separates those three things.

WordPress is not a niche content management system. According to W3Techs (31 Oct 2026), it runs 39.5% of all websites and 58.2% of those with an identifiable CMS. Inside WordPress, 67.7% already runs the 7 branch and the current stable release is 7.1.4. Any guide that presents "WordPress 6" as the present is out of date.

What WordPress Already Does on Its Own (and What It Doesn't Do at All)

Before touching anything, know what is already handled. Since 5.5 core publishes a sitemap index at /wp-sitemap.xml and references it from robots.txt by itself. Since 5.7 it adds max-image-preview:large, the directive that lets Google show large thumbnails in results and in Discover. Since 5.5 it lazy-loads images, and since 6.3 it marks the image it detects as the LCP image with fetchpriority="high".

What No Core Setting Gives You

Core does not write meta descriptions, emits no schema at all and generates no hreflang for multilingual content. It also does not output a canonical outside single pages, and that includes your category, tag and author archives. Those are four big gaps, and they are exactly the ones an SEO plugin fills.

Why "Just Install an SEO Plugin" Is an Incomplete Answer

A plugin solves that layer, but it does not change your hosting, does not uncheck the visibility switch, does not compress your images and does not fix a theme that loads five font families. If you are comparing options, the guide to WordPress SEO plugins covers that part; here we stick to technical configuration.

The Switch That Keeps an Entire Site Out of Google

Under Settings > Reading there is a checkbox called "Discourage search engines from indexing this site". Plenty of people check robots.txt, see nothing wrong and move on. That is a diagnostic mistake: since version 5.3 the checkbox no longer touches robots.txt, it prints <meta name='robots' content='noindex,nofollow' /> in the <head>, as long as the theme calls wp_head(). Only up to 5.2 did it write Disallow: / to the robots file.

The Three 60-Second Checks

First, the page source: open the homepage, search for "noindex" and confirm it is not there. Second, the response headers from the command line. Third, a site:yourdomain.com query on Google: if it does not even return the homepage, something is closing the door.

curl -s https://yourdomain.com/ | grep -i "noindex"
curl -sI https://yourdomain.com/ | head -15

The classic case is a site launched with that box checked, three months of silence and the conclusion that "Google won't index it". You uncheck it, request indexing for the homepage and within days the site is in. If your site came from a staging clone, check that box on day one.

Sitemaps: Core's, the Plugin's, and the One You Don't Need

The 5.5 index holds up to 50,000 sitemaps and each sitemap includes a maximum of 2,000 URLs, filterable with wp_sitemaps_max_urls. It generates entries for every public post type and taxonomy, for the homepage and also for author archives. With that in place, most sites do not need an external sitemap at all.

The Detail Almost Nobody Checks: There Is No lastmod

Core sitemaps ship without lastmod, and the index never accepts it. You add it with a filter on each post entry. Limits, format and when to use image or video sitemaps are already covered in the guide to sitemap indexes and lastmod.

add_filter( 'wp_sitemaps_posts_entry', function( $entry, $post ) {
    $entry['lastmod'] = get_post_modified_time( 'c', true, $post );
    return $entry;
}, 10, 2 );

The Author Sitemap You Don't Need

On a single-author site, that sitemap only adds archive URLs and exposes the username used to log in. You remove it without a plugin through the wp_sitemaps_add_provider hook, returning false when the provider name is users.

And if your SEO plugin also generates a sitemap, check which of the two you declare in robots.txt. Two sitemaps with the same content are tolerable noise in Search Console; two sitemaps with different content, where one went stale, send contradictory signals.

Pages WordPress Creates That Shouldn't Compete for Your Keywords

The tag archive lists the same posts as the category; the date archive, the same as the blog; the author archive, the same again. Google picks one version and the rest becomes duplicate content. Keep indexable only the archives that add something of their own (a category with introductory copy) and apply noindex to the rest.

Attachments: Since 6.4 New Installs Redirect Them, Old Sites Don't

Attachment pages add no meaningful information, yet they existed, got indexed and sometimes ranked, producing bad results for users. Version 6.4 disabled them on new installations. The important nuance: on existing sites the option is set to 1 on upgrade, so they stay alive. They are controlled by wp_attachment_pages_enabled.

Internal Searches and Comment Pagination

?s= generates result pages nobody reviewed that can get indexed; ?replytocom multiplies URLs for the same post. Both are handled with Disallow in robots.txt or with a canonical pointing to the post page. If your robots file needs a pass, the guide to robots.txt in 2026 has the directives and the common mistakes.

Canonicals: The Gap Core Leaves Open

Core's rel_canonical() function starts with if ( ! is_singular() ) { return; }. Literally: it only outputs a canonical on single queries. Archives, the blog index, search results and pagination get no canonical tag at all, and that is not a bug, it is the scope WordPress chose.

How to Check It Without Installing Anything

curl -s https://yourdomain.com/tag/example/ | grep -i canonical

If it returns nothing, that archive has no canonical. An SEO plugin adds one; a theme rarely does it well. And if you hardcode a canonical in the template, mind pagination: page 2 of a category must not point to page 1, because you are dropping it from the index.

Performance: What's Already Handled and What Still Hurts

Since 6.3 core marks the LCP image as high priority and never applies loading="lazy" to that same image: combining both is an anti-pattern that WordPress documentation itself calls out. Field data from that release showed a 16% to 21% mobile LCP improvement on sites that had been lazy-loading their main image. It also showed the awkward part: LCP image detection is accurate only around 50% of the time.

Speculative Loading Since 6.8

Speculative prefetching is enabled by default except for logged-in sessions or sites with permalinks disabled, and it fires when the user starts to click, a conservative setting. It excludes URLs with query parameters by default and can be tuned with wp_speculation_rules_configuration and wp_speculation_rules_href_exclude_paths. Do not switch it to prerender without auditing carts and forms: it is not the same thing as the prefetch used by resource hints.

What No Core Setting Fixes

Hosting and TTFB, PHP version, object cache, images and fonts. If your LCP is bad because of the server, no checkbox will move it. For servers, hosting and SEO; for formats, WebP and AVIF.

Plugins, Themes, and the Right Order to Touch All of This

One SEO plugin, not two. Two plugins writing title, meta description and schema step on each other: the last one to run wins and the result changes with every update. Decide who owns each piece (titles, metas, schema, sitemap, canonical, redirects) and switch off the rest. The theme, for its part, should not emit its own meta tags when a plugin is already in charge.

The order that works: visibility and indexing, permalinks, sitemap and robots, archives that should not be indexed, canonical, structured data and, last, performance. Updating core to 7.1.4 goes first on any month's list: a compromised site loses indexing faster than it regains it.

A 12-Point Audit for Your WordPress SEO

Twelve checks, in this order:

1. The homepage source contains no noindex.
2. robots.txt declares the right sitemap and blocks no required resources.
3. Permalinks are readable and stable.
4. The sitemap returns 200 and lists your published URLs.
5. Tag, author and date archives: indexable or not, but decided.
6. Attachment pages disabled if your install still carries them.
7. Archives have a canonical and pagination points to itself.
8. One single source for titles and meta descriptions.
9. Schema present on posts and on the organization.
10. The LCP image does not carry loading="lazy".
11. The core version is up to date.
12. Search Console free of manual actions and odd coverage states.

The order of attack: visibility switch and robots.txt on day one, because they can be costing you the entire site; archives and canonical on day two; performance and content after that. To keep going on internal links and loose pages, the articles on internal linking and orphan pages are the next step.