WordPress SEO without a plugin: what WordPress already does and what it leaves out

WordPress does not need an SEO plugin to be read by a search engine. With none installed it prints a title and a robots tag on every page and a canonical link on every post and page. It serves a sitemap at /wp-sitemap.xml, answers /robots.txt, and redirects the common duplicate addresses to one. What it leaves out is a meta description, the tags that shape a link's preview when a page is shared, and structured data. Those are what a plugin adds, and Google's documentation calls none of them required.

Everything below about what WordPress prints was read from a new install with no plugin active and the Twenty Twenty-Five theme. Where a result depends on the theme, the section says so.

See what your own pages print

Almost everything in this list is a tag in a page's <head>. One command prints the tags a search engine reads and leaves the rest of the page out. It runs in a terminal on the server or on your own computer, wherever curl and grep are installed.

Put your own address between the quotes: the home page, a post, a category, or a search such as https://example.com/?s=test. On the home page of the new install the command prints two lines.

A tag that is not on the page prints no line. That is how the absences further down were found. With no terminal, open the page's source in a browser and search it for the same words.

What a page prints depends on the theme and on every active plugin, so see what the site runs before you compare it with this page. These two commands need WP-CLI on the server.

What WordPress does with no plugin

A title on every page

WordPress builds the <title> from the page's own title and two settings, Site Title and Tagline, under Settings, then General. In the page source the dash between the parts is written –.

A new site has an empty tagline, so its home page is titled with the site's name and nothing else. Google's page on title links calls the home page's title "a reasonable place to include some additional information about your site", which is what the tagline adds.

The theme decides whether this title is printed at all:

• A block theme, such as the three bundled with the install tested: Twenty Twenty-Five, Twenty Twenty-Four and Twenty Twenty-Three. WordPress prints the title itself, in the words of its reference "regardless of whether theme has title-tag support". Twenty Twenty-Five does not declare that support, and the title is there.
• A classic theme. WordPress prints the title only when the theme declares support for title-tag, a feature themes have had since WordPress 4.1. A classic theme that neither declares it nor writes a title of its own serves pages with no <title>. A bare classic theme made for the test did exactly that, and gained the title once it declared the support.

What WordPress has no field for is a title that differs from the page's own heading. The title in search results is Google's to write in any case. Its documentation asks that every page have a <title> element, calls the result "completely automated", and lists the <title> first among the sources it draws on.

A robots tag

Since WordPress 5.7 one function writes the robots meta tag, and what it writes depends on the page and on one setting.

max-image-preview:large allows a search engine to show a large preview of the page's images. Google's wording for the value is that "a larger image preview, up to the width of the viewport, may be shown". A page with no robots tag at all is treated as open: Google's defaults are index, follow.

The setting behind the third row is one option. 1 means the site is open, 0 means the box is ticked.

A site launched with that box still ticked asks every search engine not to index it. What the box does, and how to check it has the detail.

WordPress has no setting to put noindex on one chosen post, page or archive. The tag is built by a filter, so it can be done in code, and it is one of the things a plugin gives a box for.

A canonical link on posts and pages

WordPress prints rel="canonical", in the words of its reference, "for singular queries". It has done so since version 2.9. On the test site that came to this:

A post requested with something added to its address, such as ?utm_source=newsletter, still names the clean address as canonical. That is the case the tag exists for.

A missing canonical on an archive is not a fault. Google calls a redirect and a rel="canonical" link each "a strong signal" and a sitemap entry "a weak signal", and then says of all of them: "none of them are required". Where a site names no canonical, Google picks one.

A sitemap

Since WordPress 5.5 a site has a sitemap index at /wp-sitemap.xml. It lists one sitemap for each kind of content.

On the new install the index named four: posts, pages, categories and authors. A fifth, for tags, appeared once a tag was in use. The developer note that introduced the feature says sitemaps cover "all public and publicly queryable post types and taxonomies", author archives and the home page, with at most 2,000 entries in a file. The same note says image, video and news sitemaps are not part of it. Each post and page entry carried a lastmod date. Category and author entries did not.

Two more things the test showed: /sitemap.xml redirects to /wp-sitemap.xml, and the sitemap answers 404 while the "Discourage search engines" box is ticked.

Google does not require a sitemap. Its Starter Guide says of submitting one that "this isn't required", and its sitemap page says a site of "about 500 pages or fewer" might not need one. The guide to wp-sitemap.xml covers which sitemap to submit and what to do when it answers 404.

A robots.txt

WordPress answers /robots.txt by itself when no file of that name is on the server.

It asks crawlers to stay out of the dashboard and points them at the sitemap. With the "Discourage search engines" box ticked, the Sitemap line goes and nothing else changes: WordPress has not written Disallow: / there since version 5.3. Where robots.txt is and how to edit it goes further.

Redirects to one address

When one page answers at several addresses, a search engine has to choose one of them. WordPress closes the usual cases by itself. This command asks for an address and prints the status and where it leads.

Each of these answered with a 301 on the test site, which had /%postname%/ permalinks:

Three limits showed in the same test:

• A page's old slug is not forwarded. After a page was renamed, its old address answered 404. WordPress does not attempt the old-slug redirect for pages or any other content type that can have parents.
• Only the www form of the host is redirected. A request under any other hostname that reaches the site is answered with a 200. The canonical link on that page still names the site's own address.
• The last row is a guess. WordPress looks for a slug that starts with what was typed, and the guess can land on the wrong page.

Changing the permalink structure is its own subject: read how to change permalinks safely first, and how to set up redirects for what WordPress does not forward.

Icon links, once you set a Site Icon

A new site prints no favicon link. Once a Site Icon is chosen, WordPress prints rel="icon" links at 32 and 192 pixels and an apple-touch-icon link, as it has since version 4.3. A rel="icon" link on the home page is what Google's favicon documentation asks for.

What WordPress does not print

The same command on the same pages found none of the following, on the home page, a post, a page or an archive. Twenty Twenty-Four and Twenty Twenty-Three were switched on in turn and printed none of them either.

A meta description

WordPress prints no <meta name="description">. Google's position is that it "primarily uses the content on the page" to write the snippet under a result, and may use the meta description "when it describes the page better than other parts of the content". The description is on Google's list of meta tags it supports. It is not a requirement, and Google writes a snippet without one.

Sharing tags

There are no Open Graph tags (og:title, og:image, og:description) and no twitter: tags. Open Graph is the protocol a site uses to name the title, image and description that stand for a page on a service that reads it, such as a social network drawing a preview of a shared link. Without the tags, the choice is left to that service.

For search, the picture is mixed. Open Graph tags are not on Google's list of supported meta tags. Three other Google pages each name one as something Google reads: og:title among the sources for a title link, og:site_name among those for a site name, and og:image as a way to suggest the thumbnail in Discover.

Structured data

There is no JSON-LD and no other schema.org markup: no WebSite, no Organization, no Article, no breadcrumb list. Structured data is, in Google's words, a way of "providing explicit clues about the meaning of a page", and it is what makes a page eligible for rich results. Three things from Google's documentation set its weight:

• For Article and for Organization it says "There are no required properties".
• For a site's name it says WebSite structured data on the home page "is most important, if you want to specify a preference". Its system also reads the home page's <title> and headings.
• It "does not guarantee that your structured data will show up in search results".

One exception is worth knowing. WooCommerce is a plugin, not an SEO plugin, and it prints Product markup on product pages by itself: see what a store outputs.

A keywords tag, which Google ignores

WordPress prints no <meta name="keywords">, and nothing is lost. Google's Starter Guide: "Google Search doesn't use the keywords meta tag."

What a plugin adds

What it adds that a search engine reads

SEO plugins describe their own additions in their WordPress.org listings. Two examples, in alphabetical order: SEOPress lists a box for editing titles, descriptions, Open Graph and X Card tags, schema, robots and canonical values, and The SEO Framework lists generated titles and descriptions, Open Graph and Twitter Card tags, and structured data. Set beside the inventory above, that is:

• A description for each page, written by you or generated.
• Sharing tags, so a shared link shows the title and image you chose.
• Structured data for the site, the organization, articles and breadcrumbs.
• A setting on each page for what WordPress decides alone: a title that differs from the heading, noindex on one page, a canonical link you choose.

A plugin may also replace something WordPress already does. Yoast SEO's changelog records that it switches WordPress's own sitemap off in favor of its own. After activating an SEO plugin, check which sitemap address answers.

What it adds that Google says it does not use

Both listings above also describe content analysis built around target or focus keywords. Google's Starter Guide has a list headed "Things we believe you shouldn't focus on". On it are the keywords meta tag, a target length ("there's no magical word count target, minimum or maximum") and the number and order of headings. Where a plugin's checklist asks for one of those, Google's guide says it does not matter.

A score or a colored light beside the editor is the plugin's own measure. Google's page on hiring an SEO says it "doesn't evaluate or endorse third-party SEO tools, and these tools don't have access to Google's internal ranking data".

What no plugin can do

A plugin writes tags. Whether Google uses them is Google's decision: it describes both title links and site names as "completely automated", and says it cannot change a snippet by hand for any site. No plugin can make a page indexed either: Google's technical requirements say "indexing isn't guaranteed". Its page on hiring help adds: "No one can guarantee a #1 ranking on Google."

A plugin also cannot supply what the page is about. The words, the images and the links between your pages are still yours to write.

The whole inventory

"The command" in the last column is the first one on this page, run on the address named.

Do you need an SEO plugin?

Not to be found. Google lists three technical requirements for a page to be eligible for its index: Googlebot is not blocked, the page answers with a 200, and it has indexable content. None of the three needs a plugin. A WordPress with none blocks no crawler from its pages and answers them with a 200, unless the "Discourage search engines" box is ticked.

For a small site, what is missing comes down to the description, the sharing tags and structured data. Whether those are worth a plugin is your call. What to weigh:

• How your pages are shared. If links to your pages are passed around on social networks, the sharing tags are how you say what the preview should show.
• Whether Google names your site the way you want. If it does not, WebSite structured data on the home page is, by Google's account, the most important way to state a preference.
• Whether you want to write your own descriptions. Google writes the snippet from the page either way and uses yours only when it judges it the better description.
• Whether you need a setting on single pages, such as keeping one thank-you page out of search.
• What a plugin costs. It is code that loads with the site, with its own updates, and it can replace your sitemap and your titles on the day it is switched on. How to choose a plugin has the checks to make first.

If you do install one, run the command at the top of this page before and after, on the same three pages. The difference between the two outputs is what the plugin does for a search engine.

If a check on this page shows something you cannot explain, such as a noindex you did not set, WP Ministry can find the cause as a one-time fix.