WordPress SEO: the best settings, what an SEO plugin adds, and a checklist

What WordPress already does for SEO

A default WordPress install already produces most of the technical signals search engines read. Knowing which ones core handles tells you what not to install a plugin for, and which gaps are yours.

What core does not do is just as important. It has no field for a meta description: WordPress's own SEO documentation notes that meta tags are not included by default and points to plugins. It leaves every tag, date and author archive indexable. It cannot know which URLs you changed in a redesign, and it is only as safe as the plugins installed around it. The rest of this guide closes those gaps, starting with the one that can hide a whole site.

Turn off "Discourage search engines from indexing this site"

One checkbox can keep an entire WordPress site out of search results: Search engine visibility under Settings > Reading. When "Discourage search engines from indexing this site" is ticked, WordPress adds a robots meta tag with noindex,nofollow to the <head> of every page and stops pinging update services. Visitors can still read everything; only search engines are asked to stay away.

Before WordPress 5.3 the setting worked differently: it added Disallow: / to robots.txt. The 5.3 change was deliberate, because a crawler that is blocked from fetching a page never reads it, and the URL can still be listed when other sites link to it. Google's noindex documentation states the same rule from the other side: for noindex to work, the page must not be blocked by robots.txt, and some search engines may interpret the rule differently.

The setting is meant for sites under construction, which is exactly how it gets left on at launch. Since WordPress 6.9, Site Health reports "Search engines are discouraged from indexing this site" as a recommended fix, so Tools > Site Health will point it out. You can also check from outside the dashboard:

curl -s https://example.com/ | grep -io '<meta name=.robots[^>]*>'

If the tag on your home page contains noindex, something is hiding the site: this setting, or an SEO plugin configured to do so.

For staging and development copies, the same WordPress note recommends sending an X-Robots-Tag: noindex, nofollow HTTP header with every response, because images and PDFs are served by the web server directly and never pass through WordPress. Putting staging behind HTTP authentication, so crawlers cannot fetch it at all, is firmer still.

Choose a permalink structure before you publish

Permalinks are the URLs of your posts, pages and archives, set under Settings > Permalinks. Depending on the server, a new site starts with Plain URLs (/?p=123), which work everywhere, or with day and name (/2026/09/25/sample-post/), which the settings screen documentation calls the default.

Google's URL structure guidance asks for readable words rather than long ID numbers, and hyphens rather than underscores between words. For most sites that makes Post name (/%postname%/) the right choice, or category and post name when categories are stable and meaningful. A custom structure should end with %postname% or %post_id% so each URL points at one post, and category and tag archives keep a base (/category/ and /tag/ by default) that you can rename but not remove in core.

The setting matters most on day one. Changing it on a live site changes every post URL at once, which is a migration (covered below). WordPress softens two smaller cases on its own. When you edit a published post's slug, it answers the old slug with a 301 to the new URL. On a 404, it guesses a redirect to a post whose slug starts with the requested name. Neither is a redirect plan: the guess is loose by default and can send a visitor to the wrong post.

XML sitemaps and robots.txt in WordPress

Since WordPress 5.5, core publishes a sitemap index at /wp-sitemap.xml. It covers public post types (posts and pages), public taxonomies (categories and tags), author archives and the home page, with up to 2,000 URLs in each sitemap by default. WordPress also adds the index to its virtual robots.txt, which otherwise only keeps crawlers out of /wp-admin/. Three details decide whether it helps:

1. It switches off with the visibility setting. When "Discourage search engines" is ticked, the core sitemap is disabled too, one more symptom to look for.

2. It lists what is public, not what is useful. Tag and author archives are included by default. On a one-author blog the author archive repeats the blog index, so either noindex it with your SEO plugin, which then drops it from its own sitemap, or remove the users sitemap from core with the filter the 5.5 notes describe:

   // Remove author archives from the core XML sitemap.
   add_filter( 'wp_sitemaps_add_provider', function ( $provider, $name ) {
   	return 'users' === $name ? false : $provider;
   }, 10, 2 );
   

3. Run one sitemap, not two. SEO plugins generate their own. Yoast's sitemap documentation, for example, asks you to disable other sitemap generators first, and leaves content types set to noindex out of its sitemap. Submit whichever sitemap is live in Search Console. Site Kit, Google's official WordPress plugin, brings Search Console data into the dashboard if you would rather not leave WordPress to check it.

Do not use robots.txt to hide thin or duplicate pages. WordPress's SEO documentation recommends page-level noindex for low-quality parts of a site instead, for the reason Google gives above: a blocked page cannot show its noindex. How crawling, rendering and indexing work beyond WordPress is covered in technical SEO.

Titles and meta descriptions: core or an SEO plugin

Core writes the title tag. On themes that declare title-tag support, which arrived in WordPress 4.1, and on block themes, WordPress builds the title with wp_get_document_title(): the post or page title, a separator (a hyphen by default) and the site title, or on the front page the site title and the tagline. So the Site Title and Tagline under Settings > General end up in search results. Write them for people.

Meta descriptions are different. Google builds most snippets from the page content and uses the meta description when it describes the page better, so a written description is worth having on pages that matter, but a missing one is not an error. Since core has no description field, this is the first thing an SEO plugin adds. Yoast SEO, Rank Math and All in One SEO are the familiar examples; this is not a ranking. Each puts an SEO title and meta description on every post and page, generates an XML sitemap, outputs schema.org structured data and lets you set content to noindex. They differ in interface and in which features sit in the free edition.

Once the plugin is in, set templates for each content type (posts, pages, categories) so every page gets a sensible default, then write titles and descriptions by hand for the pages that bring in business. Rank Math's settings documentation shows the typical layout: global defaults for robots meta, a title separator, and separate sections for post types, taxonomies, authors and date archives. What a good title or description says is covered in on-page SEO.

Noindex the archives that add nothing

WordPress creates an archive for every category, tag, author and month, and until recently a separate page for every uploaded file. Few of them answer a search. A tag used on one post produces a page that repeats that post's excerpt; a date archive lists whatever happened to be published that month; on a single-author blog the author archive duplicates the blog index. Rank Math's documentation makes the same call: it sees no need for author archives on single-author sites, says date archives should be disabled on most sites, and offers to noindex empty category and tag archives.

Attachment pages deserve a closer look, because the default depends on when the site was installed. The WordPress core team found that on most sites these pages carry no useful information yet get indexed and sometimes rank, so since WordPress 6.4 new installations redirect each attachment page to the file itself. Sites upgraded from an older version keep them switched on. With WP-CLI, one command turns them off, after which each attachment page redirects to its file:

wp option set wp_attachment_pages_enabled 0

Whatever you noindex, keep it crawlable and out of your sitemap. The 5.5 sitemap notes ask plugins that noindex content to exclude it from the sitemap, and SEO plugins do that for you.

Images: lazy loading, fetchpriority, WebP and AVIF

Images are where core has done the most performance work, and most of it runs without configuration. Since 5.5, WordPress adds loading="lazy" to images that have width and height attributes, and fills in those dimensions for images from the media library, which also stops content jumping as images load. Since 6.3, it adds fetchpriority="high" to the image it judges most likely to be the Largest Contentful Paint (LCP) element, and keeps lazy loading off the images in the first screen. WordPress says the attribute typically improves LCP by 5 to 10 percent.

That logic only sees images WordPress renders as <img> tags. A hero image printed by a slider, a page builder or a CSS background can fall outside it, and then the most important image on the page gets no priority at all. Check your main templates in PageSpeed Insights: the LCP element should load early and never carry loading="lazy". If core picks the wrong image, a developer can set fetchpriority on the right one, since WordPress never overrides an attribute that is already there.

Modern formats cut the bytes. You can upload WebP since 5.8 and AVIF since 6.5, as long as the server's image library (Imagick or GD) supports them; Tools > Site Health > Info > Media Handling lists the formats your server can process. WordPress's announcements put WebP at about 30 percent smaller than equivalent JPEG or PNG files on average, and AVIF at up to 50 percent smaller than JPEG at the same quality. Finally, fill in alternative text in the media library. It is there for people using screen readers first, and search engines read it too.

Speed: caching, theme weight and plugins

Google's Core Web Vitals set the targets: LCP within 2.5 seconds, Interaction to Next Paint (INP) under 200 milliseconds and Cumulative Layout Shift (CLS) under 0.1, measured on real visits. Google says good scores, with other page experience aspects, align with what its core ranking systems seek to reward. On WordPress, four things decide most of it.

A page cache. Without one, WordPress runs PHP and database queries for every visit. The WordPress optimization handbook sends anyone short of time straight to caching, the biggest gain for the least effort: a caching plugin, or a server cache such as Varnish, serves stored copies of pages instead. Since WordPress 6.1, Site Health checks for a page cache and flags server response times over 600 milliseconds. A persistent object cache, which needs a cache server from your host, speeds up the dynamic and logged-in requests a page cache cannot serve.

Theme and plugin weight. The same handbook says a lightweight theme performs much more efficiently than a heavy one, and that the number and quality of plugins has a large effect, so deactivate and delete what you do not use and switch plugins off one at a time on a staging copy to find the slow one. A plugin that loads its scripts and styles on every page, even where its feature never appears, charges every visitor for it.

Block themes. In a block theme, WordPress parses the blocks before writing the <head>, so it loads styles only for the blocks a page uses rather than one stylesheet for all of them; classic themes can opt in after testing. That does not make every block theme fast, since fonts, patterns and third-party blocks still add weight, but the starting point is lighter.

A current PHP version. WordPress.org recommends PHP 8.3 or newer. WordPress still runs on PHP as old as 7.4, which the same page notes has reached end of life.

Updates and security are WordPress SEO too

A hacked WordPress site is an SEO problem first, because the damage is designed to be seen by search engines. Google's spam policies describe hacked content: code injected into pages, new spam pages added to the site, hidden links or text slipped into existing pages, and redirects that only fire for some visitors, such as those arriving from Google Search.

Patchstack's State of WordPress Security in 2026, which covers 2025, shows where the risk sits:

• 11,334 new vulnerabilities in the WordPress ecosystem, 42 percent more than in 2024;
• 91 percent in plugins and 9 percent in themes, with only 6 in core, all low priority;
• 5 hours: the weighted median time from publication to first exploitation for the most heavily targeted flaws.

The same report, drawing on malware data from Monarx, names Japanese SEO spam among the dominant infection families and describes their cloaking: search engine bots get keyword-stuffed spam, human visitors are redirected to scams, and the owner looking at the site sees nothing wrong until rankings fall.

That is why the checks for a hacked site are SEO checks. Search Console's Security issues report lists hacked content Google has found; its URL Inspection tool shows a page the way Googlebot receives it, which matters because injected spam is often served to Google alone. Fix every listed issue, then request a review, which Google says takes from a few days to a few weeks.

Prevention is mostly upkeep. Since WordPress 5.5 you can switch on auto-updates plugin by plugin and theme by theme, and WordPress runs them twice a day. Delete plugins and themes you do not use, since deactivated code still sits on the server. The rest of the controls (multi-factor sign-in for admins, least privilege, a firewall, tested backups) are in our website security checklist, and restoring a clean copy is covered in website backups.

Which WordPress version to run in September 2026

As of September 25, 2026, the current release is WordPress 7.1.2, published on September 22, 2026. It is a security release for a critical vulnerability that, under certain server and theme conditions, could lead to remote code execution. The fix was backported to every branch still eligible for security fixes, but WordPress.org is clear that only the most recent version is actively supported. WordPress 7.0 shipped on May 20, 2026 and 7.1 on August 19, 2026, and the project's 2026 roadmap aims for three major releases this year, with 7.2 planned for December 10, 2026 (a date for rough planning only). The features in this guide arrived in core releases, and so do the fixes that keep spam off your pages: stay on the current major version.

Migrations, redirects and URL changes

Every URL change on WordPress is a small migration: a new permalink structure, a renamed category base, a move to HTTPS, a new domain, or a rebuild on another theme or platform. Google's site move guidance sets out the method. Map every old URL to its new one, use server-side permanent redirects, avoid chains (ideally no more than 3 hops), point internal links and sitemaps at the new URLs, and keep the redirects for as long as possible, generally at least a year.

WordPress adds its own steps to a domain move. Update the WordPress Address and Site Address (or WP_HOME and WP_SITEURL in wp-config.php), then replace the old URLs stored in the database. WordPress's moving guide warns that a blind search and replace breaks serialized data, recommends WP-CLI's search-replace command, which handles it, and says never to change the guid column, which feed readers rely on. Write the redirects at the server (in .htaccess on Apache) or with a redirect manager: the free Rank Math plugin lists one, while All in One SEO and Yoast SEO keep theirs in the paid Pro and Premium editions. Then test every old URL: one hop, straight to a page that returns 200.

A move off WordPress, or onto it, follows the same rules. Our SEO service plans migrations this way: old URLs mapped one to one, redirects tested before cutover and monitored after. When the move is part of a rebuild, our web design and development team maps and redirects every legacy URL and verifies metadata, structured data and sitemaps before the switch.

WordPress SEO checklist: the best settings and upkeep

Work through it at launch, then repeat the maintenance items monthly.

1. Settings > Reading: "Discourage search engines from indexing this site" is unticked, and the home page's robots meta tag has no noindex.
2. Settings > General: the Site Title and Tagline read well in a search result, and both site address fields use HTTPS and your preferred host.
3. Settings > Permalinks: post name, or category and post name, chosen before launch and not changed without a redirect map.
4. One SEO plugin, with title and description templates set for each content type and hand-written ones on the pages that matter.
5. One sitemap live (core or the plugin's), submitted in Search Console, with no noindexed URLs in it.
6. Archives decided: thin tag, date and author archives noindexed, and attachment pages off (wp_attachment_pages_enabled set to 0 on sites installed before 6.4).
7. robots.txt blocks nothing you want indexed, and is not used to hide thin pages.
8. Images: the LCP image has fetchpriority="high" and no lazy loading, photos are WebP or AVIF where the server supports it, and every image has alt text.
9. Speed: a page cache is on, Site Health reports no slow server response, and PHP is 8.3 or newer.
10. Theme and plugins audited, unused ones deleted, auto-updates on.
11. WordPress core on the current release (7.1.2 as of September 2026).
12. Search Console checked weekly: Security issues empty, sitemap read without errors.
13. Before any URL change: a full URL inventory, a redirect map, 301s tested in one hop.

For the order in which to fix what you find, see how to improve SEO. If you would rather hand the audit over, our SEO service starts with a crawl of the whole site and a read of Search Console, and fixes the issues rather than only reporting them.