WordPress SEO Guidelines

Here is the thing nobody tells you before you install WordPress: it has no opinion about what you are building. Not a soft opinion, not a gentle nudge, none. Shopify assumes you are selling products and hands you a cart. Wix assumes you want something pretty fast and hands you a template. WordPress assumes nothing, hands you an empty database and a login screen, and waits. That absence of assumption is the single most important fact about WordPress SEO, and almost everything else in this guide is a consequence of it.

Because there is no ceiling, WordPress powers roughly four in ten of all websites, from a single person's recipe blog to newspaper sites handling ten million visits a day. But because there is also no floor, no safety rail, no "you cannot possibly break this" default, WordPress also produces more badly-configured, plugin-strangled, mysteriously slow websites than any other platform on this list, combined. Same software. Wildly different outcomes. The difference is never WordPress. It is what you built on it, and who you let near the build.

No default ceiling, no default floor

Every other platform in this chapter trades freedom for guardrails. Shopify will not let you break checkout because it will not let you touch checkout. Wix will not let you accidentally serve a 40-megabyte homepage because its own editor will not let you upload one without a fight. WordPress has no such trade. WordPress core, the actual open-source software, is roughly a content database, a template renderer and an admin screen. That is the whole product. Everything you associate with "a WordPress site", the SEO fields, the page builder, the contact form, the image compression, the caching, arrives later, from someone else's code, installed by you, running under your responsibility.

This is why the honest answer to "is WordPress good for SEO" is neither yes nor no. WordPress has no SEO ceiling in either direction. A well-run WordPress site can out-rank anything built on any other platform, because nothing stops it scaling to hundreds of thousands of pages with clean architecture. A badly-run WordPress site can also become one of the slowest, least crawlable messes on the internet, because nothing stops that either. The platform is neutral. The build quality is not.

So WordPress SEO, properly understood, is this: you have the most freedom of any platform on this list, and also the most rope to hang yourself with. Every single complaint you have ever heard about WordPress and SEO, the bloat, the plugin conflicts, the security holes, the twelve different sitemaps fighting for attention, is really a contractor-management problem. It is not a limitation of the software. It is a limitation of how the site was staffed.

Permalinks: the setting everyone forgets on day one

Before plugins, before themes, before a single word of content, there is one setting that decides your URL structure for the rest of the site's life, and WordPress does not get it right by default. Go to Settings, then Permalinks, and you will very likely find it set to "Plain", which produces URLs that look like yoursite.com/?p=123. That URL tells a search engine nothing about the page. It tells a human even less. And changing it later, once the site has pages, backlinks and rankings attached to those numeric URLs, means either a mass 301 redirect exercise or accepting broken links across the internet.

The fix takes ninety seconds and should happen before you publish a single page. Switch the permalink structure to "Post name", which turns that same URL into yoursite.com/your-page-title. It is descriptive, it is short, it matches what every SEO guide since 2006 has recommended, and it is the one setting on this entire page with a genuine "set once, forget forever" quality, provided you set it on day one rather than day two hundred.

Beyond the base structure, resist the urge to stuff dates, categories, or author names into every URL automatically through permalink tags. A URL like yoursite.com/2019/03/12/category/post-title looks organised in the admin screen and looks like clutter in a search result. Keep the structure flat: post name only for most sites, and if you are running a large publisher with genuine need for category context in the URL, add category once, not date and category and author stacked on top of each other.

Choosing one SEO plugin, and configuring it properly

WordPress core has no meta description field, no XML sitemap, no schema markup, no canonical tag control. All of that arrives through a plugin, and this is where most WordPress SEO setups go wrong in the first ten minutes, not through bad advice but through generosity: installing more than one plugin that claims to do the same job, because each one looked useful on its own.

Pick one general-purpose SEO plugin. Yoast SEO and Rank Math are the two serious options, and either is genuinely fine. Rank Math ships more features in its free tier and has a lighter interface; Yoast has the longer history, the calmer defaults, and a slightly more conservative approach to automation. The difference between them, for most sites, is a rounding error next to the difference between running one properly configured plugin and running two.

Once you have picked one, configure it rather than accepting the defaults and moving on. At minimum: set your title and meta description templates for posts, pages and any custom content types, connect the sitemap module and submit it in Search Console, decide your default social sharing image, and check the schema settings actually reflect what the page is (an article should output Article schema, a product page should output Product schema, not a leftover default). This is a twenty-minute job done once. Skipping it is how sites end up with every page sharing the same generic meta description, which is a small thing that quietly costs click-through rate on every single result for years.

The specific danger, worth naming directly: never run two SEO plugins at once, even "temporarily" while you evaluate one against the other. Both will try to write meta tags into your page head. Both may try to generate a sitemap. Both may inject schema markup. You will not get the better of the two features, you will get duplicate title tags, two sitemap files at two different URLs, and schema markup that contradicts itself, all invisible to you in the admin screen and all visible to Google, which is exactly the audience you do not want confused.

The bloat and conflict problem, beyond the SEO plugin

The two-plugin trap is not limited to SEO plugins specifically, it is the general shape of every WordPress problem. Page builders, caching plugins and image optimisation plugins all reach into overlapping territory, and a site accumulates them one at a time, each installed to solve one problem, none of them ever reviewed as a set.

A page builder like Elementor or Divi generates its own markup, sometimes wraps content in extra layers of container divs that add weight without adding meaning, and occasionally fights with your theme's own styling. A caching plugin decides how aggressively to store static versions of your pages, and two caching plugins running together will serve stale versions of each other's cached files, which shows up as "my changes aren't appearing" panic more often than any other WordPress support ticket. An image optimisation plugin compresses and resizes images on upload, and a second one doing the same job either wastes server resources doing it twice or, worse, corrupts images that the first plugin already processed.

None of this is really about the individual plugins being bad. Most are well-built, by competent teams, for a genuine purpose. The problem is a website with fourteen active plugins, several of which do overlapping jobs, none of which anyone can name a clear reason for keeping. Go into Plugins in the admin screen once a quarter and ask, for each one, what specific job it does that nothing else on the site already does. If you cannot answer that in one sentence, that plugin is a contractor nobody remembers hiring, still on the payroll, occasionally undoing someone else's work.

Every plugin you install is a contractor you have hired without an interview. Most will do their one job quietly. The damage comes from the ones doing a job someone else on site is already doing.

Page speed on WordPress, and the hosting reputation it does not deserve

WordPress has a worse reputation for speed than the software itself earns, and the reputation exists because of where most WordPress sites live: cheap shared hosting, sharing a server's CPU and memory with hundreds of other tenants, any one of which can slow your site down through no fault of your own. A WordPress site on solid managed hosting, properly configured, is not meaningfully slower than an equivalent site on any other CMS. A WordPress site on the cheapest hosting plan available, with a bloated theme and six caching plugins undoing each other, will be the slowest thing on the internet, and neither of those outcomes is really about WordPress.

Three things move the needle more than anything else. First, hosting: paying for genuinely good managed WordPress hosting, rather than the cheapest shared plan a domain registrar upsold you into, fixes more speed problems than any plugin will. Second, images: WordPress does not compress or resize images intelligently by default, so a photo straight off a modern phone, several megabytes at full resolution, gets uploaded and served at that size even when displayed in a 400-pixel-wide box on the page. An image optimisation plugin or a pre-upload compression habit closes this gap immediately and usually does more for page speed than every other fix combined. Third, caching: a single well-configured caching plugin, serving static HTML instead of rebuilding the page from the database on every visit, is close to mandatory for any WordPress site expecting real traffic.

Do those three things, in that order, before you touch a single line of custom code or install a "speed optimisation" plugin promising fifteen simultaneous fixes. Most speed problems on WordPress are these three, stacked, and most speed plugins are trying to compensate for hosting and images that should have been fixed at the source.

Themes, page builders and Core Web Vitals

Your theme is the closest thing WordPress has to a foundation, and foundations vary enormously in quality. A lightweight, well-coded theme loads a handful of stylesheets and scripts and gets out of the way. A heavy multipurpose theme, the kind sold as "one theme, a thousand demo layouts", often ships every feature for every possible use case loaded on every page, whether that page uses the feature or not. That is dead weight on every single page load, and it shows up directly in Core Web Vitals scores, particularly Largest Contentful Paint and Cumulative Layout Shift, both of which Google uses as ranking signals.

Page builders compound this in a specific way. Visual, drag-and-drop builders are genuinely useful for people who cannot or do not want to write code, and they generate working pages fast. What they also tend to generate is markup with far more nested divs than a hand-coded page would need, plus their own CSS and JavaScript libraries loaded on every page regardless of whether that specific page uses the builder's fancier widgets. A landing page built with a heavy builder can easily ship triple the code weight of the same page hand-coded in a lean theme, for an identical visual result.

This does not mean avoid page builders entirely. It means choose a lighter one, test your actual Core Web Vitals scores with real pages rather than trusting a theme's marketing claims, and remember that the contractor picture applies here too: a page builder is a contractor with a very fast, very generic building method, and fast generic building methods are rarely the leanest ones. If your site is small and simple, a lightweight theme with the native block editor will usually out-perform any page builder on speed, because there is simply less code shipped to produce the same page.

Sitemaps, robots.txt, and where structured data should live

Your XML sitemap and robots.txt file are, on almost every WordPress site, generated by a plugin rather than hand-written, and this is fine, provided exactly one plugin is doing the generating. The danger sits exactly where it sat with the SEO plugin question earlier: install an SEO plugin that includes sitemap generation, then separately install a dedicated sitemap plugin because a tutorial recommended it, and you now have two sitemap files living at two different URLs, both technically valid, both partially out of date relative to each other, and no way for Google to know which one is the intended source of truth. Check Settings inside your SEO plugin, confirm the sitemap module is switched on, submit that one sitemap URL in Google Search Console, and resist adding a second sitemap tool on top of it.

Robots.txt on WordPress is usually virtual, generated on the fly by whichever SEO plugin is active, rather than sitting as a static file you edit directly. That is normally fine and one less thing to maintain by hand. Where it goes wrong is when a plugin conflict or a leftover static robots.txt file from a previous setup silently overrides the plugin's version, and the file ends up blocking search engines from crawling folders that should be open, or leaving open folders that should be blocked, like internal search result pages or admin-adjacent paths that add no value in search.

Structured data, the schema markup that produces rich results in search, follows the identical rule. Let your one SEO plugin handle the standard types, Article, Product, Organisation, Breadcrumb, FAQ, because it is already reading your page content and page type to generate that markup correctly and consistently. Only reach for a custom schema plugin or hand-coded JSON-LD when you need a schema type your main plugin genuinely does not support, and even then, check first whether your plugin has a manual schema field before adding an entirely separate tool for one specific need.

This is the empty plot picture again, in a different room of the house. A sitemap is like a single master blueprint of every room in the building, handed to the city planning office. Two plugins each generating their own sitemap is two different blueprints for the same house, filed with two different departments, disagreeing about where the staircase is. Nobody outside your build team benefits from that redundancy, and the search engine reading both is the one left confused about which floor plan to trust.

The keyword data behind this topic

Worth being straightforward about where these numbers come from: Ahrefs access was unavailable for this particular pass, so the figures below are careful, experience-based estimates rather than a fresh pull, and they should be treated as directional until the next real refresh. That said, the shape of the picture is clear enough to act on.

Read across that table and the picture is a funnel, not four separate topics. "Wordpress seo" is the umbrella term everyone starts from, at real difficulty because a decade of agencies and plugin vendors have all written a version of this exact page. "Wordpress seo plugin" is the same population one click further into a buying decision. The checklist and the "how to" query are both lower-competition entry points for people who have not yet decided anything, which makes them worth targeting even though the raw volume looks modest next to the head term.

Security's quiet relationship with SEO

Security rarely gets mentioned in the same breath as SEO, and on WordPress specifically, it should. WordPress's popularity, the same popularity that makes it the most-supported CMS on earth, also makes it the most-targeted CMS on earth for automated attacks, and outdated plugins, outdated themes, and weak admin passwords are the three doors those attacks walk through most often.

The direct SEO consequence of a hacked WordPress site is not subtle. Malware injections frequently insert hidden spam links or entire spam page networks into a compromised site, invisible to a normal visitor but fully visible to Google's crawler, and Google's response to detecting this is to flag the site with a search interstitial warning or drop it from results outright while it investigates. Recovery, even after the malware is cleaned, is not instant. Rankings built over years can take weeks or months to recover after a hack, and some links, once indexed as spam by association, damage the site's trust signals well past the point the malware itself is removed.

The fix is unglamorous and cheap relative to the cost of a hack: keep WordPress core, your theme, and every plugin updated, remove any plugin or theme you are not actively using rather than leaving it dormant on the server as an unpatched door, use a real password manager rather than a memorable one, and put a basic security plugin in place for login attempt limiting and file change monitoring. None of that is SEO advice in the traditional sense. All of it protects the SEO equity a site has already earned.

Common mistakes, named plainly

Some WordPress SEO mistakes are subtle. Most are not, and naming them plainly is more useful than hedging around them.

• Leaving "Discourage search engines from indexing this site" ticked after launch. This checkbox lives under Settings, then Reading, and it is ticked by default on many staging setups and left there by developers who mean to untick it before launch and simply forget. The result is a fully finished, fully live website that is invisible to Google, sometimes for months, and it is the single funniest and most common self-inflicted WordPress SEO wound in existence, because the fix takes four seconds and the damage takes months to notice.
• Running two SEO plugins simultaneously. Covered above in detail because it deserves the detail: duplicate meta tags, duplicate sitemaps, contradictory schema, all at once.
• Never setting permalinks away from the default. Numeric URLs that tell nobody, human or crawler, anything about the page they lead to.
• Installing plugins for problems the theme or an existing plugin already solves. The bloat problem in miniature, repeated one plugin at a time until the admin panel lists thirty active plugins and nobody remembers what half of them do.
• Uploading images straight from a phone or camera at full resolution. Multi-megabyte files displayed in a 400-pixel box, multiplied across every image on every page, is one of the single biggest avoidable page speed costs on WordPress.
• Ignoring core, theme and plugin updates because "it's working fine." Working fine and secure are different states, and the gap between them is exactly where hacks and the SEO damage that follows tend to live.
• Treating the free hosting or cheapest shared plan as a permanent home for a serious site. Fine for a hobby blog, a real liability the moment the site carries commercial weight.

Return to the empty plot one more time, because it explains why this list looks the way it does. Every mistake above is a contractor problem: a checkbox nobody supervised, two electricians wiring the same panel, a foundation nobody inspected before building on top of it, a security guard nobody hired. WordPress did not cause any of these. It simply declined to stop them, because stopping them was never its job. That is the trade you accepted the day you chose the platform with no ceiling, and managing it well is the entire discipline of WordPress SEO.