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

> WordPress SEO step by step: the search visibility setting, permalinks, core sitemaps, an SEO plugin for titles, thin archives, images, speed and updates.

- URL: https://computese.com/wordpress-seo/
- Author: Duong Quan Nguyen, CEO, Computese
- Published: 2024-06-17
- Updated: 2026-09-25
- Topics: SEO

## In short
- WordPress core already prints title tags, canonical tags on single posts, an XML sitemap at /wp-sitemap.xml and a robots.txt, and redirects changed slugs. Most WordPress SEO is configuring and maintaining what sits around that.
- Check Settings > Reading first: “Discourage search engines from indexing this site” adds noindex, nofollow to every page and switches off the core sitemap. Since WordPress 6.9, Site Health flags it.
- Add one SEO plugin (Yoast SEO, Rank Math and All in One SEO are common examples) for meta descriptions and noindex controls, then noindex thin tag, date, author and attachment pages.
- Security is ranking work: in Patchstack's 2025 data, 91% of 11,334 new WordPress vulnerabilities were in plugins, and hacked sites serve spam to search engines. Keep core (7.1.2 in September 2026) and plugins updated.

WordPress SEO is mostly configuration you set once and then check. Make sure "Discourage search engines from indexing this site" is off, pick a post-name permalink structure, submit the XML sitemap WordPress builds, add one SEO plugin for titles and meta descriptions, noindex thin archives, keep pages fast, and keep core and plugins updated.

This guide covers the part of [SEO](https://computese.com/what-is-seo/) that is specific to WordPress, as of WordPress 7.1 in September 2026: the settings screens, what core already does, what an SEO plugin adds, and the maintenance that protects rankings. The checklist that applies to any website is in our [SEO tips for websites](https://computese.com/seo-tips-for-websites-boost-your-online-presence/), and WooCommerce and other stores have problems of their own, covered in [e-commerce SEO](https://computese.com/e-commerce-seo/).

## 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.

| Core feature              | Since                                                                                                                                                                                      | What it does                                                                                   |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------- |
| Title tag                 | [4.1](https://developer.wordpress.org/reference/functions/add_theme_support/) (block themes: [5.8](https://developer.wordpress.org/reference/functions/_block_template_render_title_tag/)) | Prints a `<title>` built from the page title and the site title                                |
| Canonical tag             | [2.9](https://developer.wordpress.org/reference/functions/rel_canonical/)                                                                                                                  | Adds `rel="canonical"` to single posts, pages and attachments; archives get none               |
| Canonical redirect        | [2.3](https://developer.wordpress.org/reference/functions/redirect_canonical/)                                                                                                             | Sends `www` and non-`www` requests to the one site address you set                             |
| Old slug redirect         | [2.1](https://developer.wordpress.org/reference/functions/wp_old_slug_redirect/)                                                                                                           | Answers a post's previous slug with a 301 to its current URL                                   |
| robots.txt                | [2.1](https://developer.wordpress.org/reference/functions/do_robots/)                                                                                                                      | Serves a virtual file that keeps crawlers out of `/wp-admin/` but allows `admin-ajax.php`      |
| XML sitemap               | [5.5](https://make.wordpress.org/core/2020/07/22/new-xml-sitemaps-functionality-in-wordpress-5-5/)                                                                                         | Publishes `/wp-sitemap.xml` and lists it in robots.txt                                         |
| Noindex on search results | [5.7](https://developer.wordpress.org/reference/functions/wp_robots_noindex_search/)                                                                                                       | Marks the site's own search result pages `noindex`                                             |
| Image loading             | 5.5 and 6.3                                                                                                                                                                                | Lazy-loads images further down the page and gives the likely main image `fetchpriority="high"` |

What core does not do is just as important. It has no field for a meta description: WordPress's own [SEO documentation](https://wordpress.org/documentation/article/search-engine-optimization/) 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](https://wordpress.org/documentation/article/settings-reading-screen/) 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](https://make.wordpress.org/core/2019/09/02/changes-to-prevent-search-engines-indexing-sites/) 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](https://developers.google.com/search/docs/crawling-indexing/block-indexing) 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.

![A web page with an orange tag clipped to its top is read by a magnifying glass, but the arrow onward to the search index drawer is blocked, so the page stays out.](https://computese.com/images/blog/wordpress-seo/visibility.26d2fe9e5f-1536.webp)

*The checkbox does not hide the site from people. It asks crawlers to read the pages and then leave them out of the index.*

The setting is meant for sites under construction, which is exactly how it gets left on at launch. Since WordPress 6.9, [Site Health](https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-admin/includes/class-wp-site-health.php) 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:

```bash
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.

> [!WARNING]
> The setting lives in the database. Copying a staging database over the live site copies a ticked box with it, so check **Settings > Reading** after every database import or migration.

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](https://wordpress.org/documentation/article/customize-permalinks/) URLs (`/?p=123`), which work everywhere, or with day and name (`/2026/09/25/sample-post/`), which the [settings screen documentation](https://wordpress.org/documentation/article/settings-permalinks-screen/) calls the default.

| Structure              | Example                    | Trade-off                                                           |
| ---------------------- | -------------------------- | ------------------------------------------------------------------- |
| Plain                  | `/?p=123`                  | Works everywhere, says nothing about the page                       |
| Day and name           | `/2026/09/25/sample-post/` | Dates every URL, so an updated evergreen post still looks old       |
| Post name              | `/sample-post/`            | Short and readable; the slug does all the work                      |
| Category and post name | `/seo/sample-post/`        | Adds context, but moving a post to another category changes its URL |

Google's [URL structure guidance](https://developers.google.com/search/docs/crawling-indexing/url-structure) 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](https://developer.wordpress.org/reference/functions/wp_old_slug_redirect/) to the new URL. On a 404, it [guesses a redirect](https://developer.wordpress.org/reference/functions/redirect_guess_404_permalink/) 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](https://make.wordpress.org/core/2020/07/22/new-xml-sitemaps-functionality-in-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](https://developer.wordpress.org/reference/functions/do_robots/), 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:

   ```php
   // 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](https://yoast.com/help/xml-sitemaps-in-the-wordpress-seo-plugin/), 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](https://wordpress.org/plugins/google-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](https://wordpress.org/documentation/article/search-engine-optimization/) 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](https://computese.com/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()`](https://developer.wordpress.org/reference/functions/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](https://developers.google.com/search/docs/appearance/snippet) 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](https://wordpress.org/plugins/wordpress-seo/), [Rank Math](https://wordpress.org/plugins/seo-by-rank-math/) and [All in One SEO](https://wordpress.org/plugins/all-in-one-seo-pack/) 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.

> [!IMPORTANT]
> Run one SEO plugin. Two plugins that both print titles, descriptions, canonical tags and sitemaps produce duplicates and conflicts, and each assumes it is the only one.

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](https://rankmath.com/kb/titles-and-meta/) 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](https://computese.com/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](https://rankmath.com/kb/titles-and-meta/) 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.

![A site tree links a home page to three full posts and four near-empty archive pages. The thin pages sit inside an orange dashed boundary, and a sitemap on the right lists only the posts.](https://computese.com/images/blog/wordpress-seo/archives.812b015bec-1536.webp)

*Keep crawlers on the pages that answer searches. Archives that only repeat excerpts add URLs without adding answers.*

| Archive                     | Keep it indexed when                                            | Otherwise                                |
| --------------------------- | --------------------------------------------------------------- | ---------------------------------------- |
| Category                    | Categories are few, curated and open with a useful introduction | Noindex, or merge thin categories        |
| Tag                         | The tag gathers many posts and you would link to it yourself    | Noindex; stop creating one-post tags     |
| Date (`/2026/09/`)          | Rarely: a news site whose readers browse by date                | Noindex or disable                       |
| Author (`/author/name/`)    | Several authors, each with a real profile                       | Noindex on single-author sites           |
| Attachment (one per upload) | Almost never                                                    | Turn attachment pages off                |
| Internal search (`/?s=`)    | Never                                                           | Nothing to do: core already adds noindex |

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](https://make.wordpress.org/core/2023/10/16/changes-to-attachment-pages/) 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:

```bash
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"`](https://make.wordpress.org/core/2020/07/14/lazy-loading-images-in-5-5/) 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"`](https://make.wordpress.org/core/2023/07/13/image-performance-enhancements-in-wordpress-6-3/) 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.

![A phone shows a page whose large top image, in orange, arrives first from a server, while three smaller images below a dashed fold line wait as empty outlines.](https://computese.com/images/blog/wordpress-seo/lcp.46c1089a3d-1536.webp)

*The image a visitor sees first is fetched first; the rest wait until the reader scrolls toward them.*

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](https://make.wordpress.org/core/2021/06/07/wordpress-5-8-adds-webp-support/) and [AVIF since 6.5](https://make.wordpress.org/core/2024/02/23/wordpress-6-5-adds-avif-support/), 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](https://developers.google.com/search/docs/appearance/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](https://developer.wordpress.org/advanced-administration/performance/optimization/) 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](https://make.wordpress.org/core/2021/07/01/block-styles-loading-enhancements-in-wordpress-5-8/) 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](https://wordpress.org/about/requirements/). 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](https://developers.google.com/search/docs/essentials/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](https://patchstack.com/whitepaper/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](https://support.google.com/webmasters/answer/9044101) 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](https://wordpress.org/documentation/article/plugins-themes-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](https://computese.com/essential-tips-to-secure-your-website/), and restoring a clean copy is covered in [website backups](https://computese.com/the-importance-of-backup-solutions-for-website/).

### Which WordPress version to run in September 2026

As of September 25, 2026, the current release is [WordPress 7.1.2](https://wordpress.org/download/releases/), published on September 22, 2026. It is a [security release](https://wordpress.org/news/2026/09/wordpress-7-1-2-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](https://wordpress.org/about/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](https://computese.com/website-migration-seo/): 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](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) 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.

| Change                         | What happens to old URLs                               | What to do                                                      |
| ------------------------------ | ------------------------------------------------------ | --------------------------------------------------------------- |
| Edit one post's slug           | WordPress answers the old slug with a 301              | Update internal links to the new URL                            |
| Change the permalink structure | Every post URL changes; WordPress only guesses on 404s | Map and 301 every post before switching                         |
| Rename the category base       | Every category archive URL changes                     | 301 the old archive URLs                                        |
| Move from HTTP to HTTPS        | Every URL changes scheme                               | Site-wide 301, HTTPS in both site address fields                |
| Move to a new domain           | Every URL changes host                                 | 301 map, then Change of Address in Search Console               |
| New theme, same URLs           | URLs survive; headings, markup and speed may not       | Compare titles, canonicals and structured data before and after |

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](https://developer.wordpress.org/advanced-administration/upgrade/migrating/) 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](https://wordpress.org/plugins/seo-by-rank-math/) plugin lists one, while [All in One SEO](https://wordpress.org/plugins/all-in-one-seo-pack/) and [Yoast SEO](https://wordpress.org/plugins/wordpress-seo/) keep theirs in the paid Pro and Premium editions. Then test every old URL: one hop, straight to a page that returns 200.

> [!TIP]
> Before any URL change, crawl the live site and export every URL, including media files and old posts that still earn links. The redirect map is only as complete as that list.

A move off WordPress, or onto it, follows the same rules. Our [SEO service](https://computese.com/services/seo/) 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](https://computese.com/services/web-design-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](https://computese.com/how-to-improve-seo-a-comprehensive-guide/). If you would rather hand the audit over, our [SEO service](https://computese.com/services/seo/) starts with a crawl of the whole site and a read of Search Console, and fixes the issues rather than only reporting them.

## Key terms
- **Search engine visibility**: The Settings > Reading checkbox “Discourage search engines from indexing this site”. When it is ticked, WordPress adds a noindex, nofollow robots meta tag to every page and turns off its core sitemap.
- **Permalink**: The permanent URL of a post, page or archive. WordPress builds it from the structure chosen under Settings > Permalinks, such as /%postname%/.
- **XML sitemap**: A file that lists the URLs you want search engines to crawl. WordPress core has published one at /wp-sitemap.xml since version 5.5; SEO plugins usually replace it with their own.
- **noindex**: A robots meta tag or X-Robots-Tag header value that asks search engines to leave a page out of their results. The page must stay crawlable, or the instruction is never seen.
- **Canonical tag**: A link element with rel=canonical that names the preferred URL for a page. WordPress core adds one to single posts, pages and attachments, not to archives.
- **Attachment page**: A page WordPress can create for each uploaded media file. Since WordPress 6.4, new installations redirect these pages to the file itself.
- **Largest Contentful Paint (LCP)**: The Core Web Vital that times how long the largest element in the viewport takes to render. Google's target for a good experience is within 2.5 seconds.
- **fetchpriority**: An HTML attribute that tells the browser how early to fetch a resource. Since WordPress 6.3, core adds fetchpriority=high to the image most likely to be the LCP element.
- **301 redirect**: A permanent, server-side redirect from an old URL to its replacement. Google recommends this kind of redirect when a site moves or its URLs change.

## Common questions

### Is WordPress good for SEO?

Yes, as a base. Core prints title tags, adds canonical tags to single posts, publishes an XML sitemap and a robots.txt, and redirects changed slugs. What decides the result is configuration and upkeep: the visibility setting, permalinks, thin archives, speed and security.

### Do I need an SEO plugin for WordPress?

Not for the basics, which core already covers. You need one for meta descriptions, per-page noindex, control over archives and richer structured data. Install one SEO plugin, not two, and switch off the features you do not use.

### What are the best SEO settings for WordPress?

Leave the “Discourage search engines” box unticked, use post-name permalinks, put HTTPS and your preferred host in both site address fields, submit one sitemap to Search Console, noindex thin tag, date and author archives, turn attachment pages off, and run a page cache.

### Which SEO plugin is best for WordPress?

Yoast SEO, Rank Math and All in One SEO all handle titles, meta descriptions, XML sitemaps and schema markup. They differ in interface and in which features sit in the free or paid edition, so compare those for your site, pick one and learn its settings.

### Why is my WordPress site not showing up on Google?

Look at the robots meta tag in the home page's source first: noindex means the Discourage box or a plugin is hiding the site. Then inspect the home page with URL Inspection in Search Console, check the Security issues report and submit your sitemap. A new site can also simply need time to be crawled.

### Should I noindex tags and categories in WordPress?

Noindex tags that hold one or two posts and any archive you would not link to yourself. Keep categories indexed when they are few and curated and open with an introduction worth reading. Use noindex rather than robots.txt, so search engines can see the instruction.

## Sources
1. [add_theme_support()](https://developer.wordpress.org/reference/functions/add_theme_support/), WordPress Developer Resources
2. [_block_template_render_title_tag()](https://developer.wordpress.org/reference/functions/_block_template_render_title_tag/), WordPress Developer Resources
3. [rel_canonical()](https://developer.wordpress.org/reference/functions/rel_canonical/), WordPress Developer Resources
4. [redirect_canonical()](https://developer.wordpress.org/reference/functions/redirect_canonical/), WordPress Developer Resources
5. [wp_old_slug_redirect()](https://developer.wordpress.org/reference/functions/wp_old_slug_redirect/), WordPress Developer Resources
6. [do_robots()](https://developer.wordpress.org/reference/functions/do_robots/), WordPress Developer Resources
7. [New XML Sitemaps Functionality in WordPress 5.5](https://make.wordpress.org/core/2020/07/22/new-xml-sitemaps-functionality-in-wordpress-5-5/), Make WordPress Core
8. [wp_robots_noindex_search()](https://developer.wordpress.org/reference/functions/wp_robots_noindex_search/), WordPress Developer Resources
9. [Search Engine Optimization](https://wordpress.org/documentation/article/search-engine-optimization/), WordPress.org Documentation
10. [Settings Reading Screen](https://wordpress.org/documentation/article/settings-reading-screen/), WordPress.org Documentation
11. [Changes to prevent search engines indexing sites](https://make.wordpress.org/core/2019/09/02/changes-to-prevent-search-engines-indexing-sites/), Make WordPress Core
12. [Block Search indexing with noindex](https://developers.google.com/search/docs/crawling-indexing/block-indexing), Google Search Central
13. [class-wp-site-health.php (WordPress source)](https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-admin/includes/class-wp-site-health.php), WordPress (GitHub)
14. [Customize permalinks](https://wordpress.org/documentation/article/customize-permalinks/), WordPress.org Documentation
15. [Settings Permalinks Screen](https://wordpress.org/documentation/article/settings-permalinks-screen/), WordPress.org Documentation
16. [URL structure best practices for Google](https://developers.google.com/search/docs/crawling-indexing/url-structure), Google Search Central
17. [redirect_guess_404_permalink()](https://developer.wordpress.org/reference/functions/redirect_guess_404_permalink/), WordPress Developer Resources
18. [XML sitemaps in the Yoast SEO plugin](https://yoast.com/help/xml-sitemaps-in-the-wordpress-seo-plugin/), Yoast
19. [Site Kit by Google](https://wordpress.org/plugins/google-site-kit/), WordPress.org Plugin Directory
20. [wp_get_document_title()](https://developer.wordpress.org/reference/functions/wp_get_document_title/), WordPress Developer Resources
21. [Control your snippets in search results](https://developers.google.com/search/docs/appearance/snippet), Google Search Central
22. [Yoast SEO](https://wordpress.org/plugins/wordpress-seo/), WordPress.org Plugin Directory
23. [Rank Math SEO](https://wordpress.org/plugins/seo-by-rank-math/), WordPress.org Plugin Directory
24. [All in One SEO](https://wordpress.org/plugins/all-in-one-seo-pack/), WordPress.org Plugin Directory
25. [Rank Math 'Titles and Meta' Options and Settings](https://rankmath.com/kb/titles-and-meta/), Rank Math
26. [Changes to attachment pages](https://make.wordpress.org/core/2023/10/16/changes-to-attachment-pages/), Make WordPress Core
27. [Lazy-loading images in 5.5](https://make.wordpress.org/core/2020/07/14/lazy-loading-images-in-5-5/), Make WordPress Core
28. [Image performance enhancements in WordPress 6.3](https://make.wordpress.org/core/2023/07/13/image-performance-enhancements-in-wordpress-6-3/), Make WordPress Core
29. [WordPress 5.8 adds WebP support](https://make.wordpress.org/core/2021/06/07/wordpress-5-8-adds-webp-support/), Make WordPress Core
30. [WordPress 6.5 adds AVIF support](https://make.wordpress.org/core/2024/02/23/wordpress-6-5-adds-avif-support/), Make WordPress Core
31. [Understanding Core Web Vitals and Google search results](https://developers.google.com/search/docs/appearance/core-web-vitals), Google Search Central
32. [Optimization](https://developer.wordpress.org/advanced-administration/performance/optimization/), WordPress Advanced Administration Handbook
33. [Block-styles loading enhancements in WordPress 5.8](https://make.wordpress.org/core/2021/07/01/block-styles-loading-enhancements-in-wordpress-5-8/), Make WordPress Core
34. [Requirements](https://wordpress.org/about/requirements/), WordPress.org
35. [Spam policies for Google web search](https://developers.google.com/search/docs/essentials/spam-policies), Google Search Central
36. [State of WordPress Security in 2026](https://patchstack.com/whitepaper/state-of-wordpress-security-in-2026/), Patchstack
37. [Security issues report](https://support.google.com/webmasters/answer/9044101), Google Search Console Help
38. [Plugin and themes auto-updates](https://wordpress.org/documentation/article/plugins-themes-auto-updates/), WordPress.org Documentation
39. [Releases](https://wordpress.org/download/releases/), WordPress.org
40. [WordPress 7.1.2 Release](https://wordpress.org/news/2026/09/wordpress-7-1-2-release/), WordPress News
41. [Roadmap](https://wordpress.org/about/roadmap/), WordPress.org
42. [Site moves with URL changes](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes), Google Search Central
43. [Moving WordPress](https://developer.wordpress.org/advanced-administration/upgrade/migrating/), WordPress Advanced Administration Handbook