The short answer
WordPress SEO is the work of fixing the problems the platform creates for itself: archive pages nobody meant to publish, plugins overwriting each other's tags, and themes loading assets on every page. The content rules are the same as any site. The failure modes are not.
What the work covers
- An indexation audit, so you can see every URL WordPress has quietly published
- Archive, tag and attachment page decisions, made deliberately rather than by default
- A plugin conflict check on the tags plugins fight over
- SEO plugin configuration past the green light, including the settings that matter
- Theme and asset cleanup so pages stop loading scripts they never use
- Core Web Vitals work at the template level
- Ongoing updates and backups if you want the site maintained too
How WordPress loses rankings in ways other platforms don't
Archives publish pages you never wrote.
Every category and every tag gets its own URL, and so does every author and every date. Tag three hundred posts with slightly different phrases and WordPress creates three hundred indexable pages, each holding an excerpt of content that already exists elsewhere. Google crawls them, works out they duplicate your posts, and spends crawl budget on pages nobody wants. Categories usually earn their place because they group things a reader wants grouped. Tags almost never do. Noindex what has no audience, keep what does, rather than applying a blanket rule from a blog post.
Attachment pages are worse.
Upload an image and WordPress can generate a whole URL for it, a page holding one picture and no useful text. A site with 900 media files can carry 900 of them. Newer themes tend not to, older sites often still do. Check before you assume.
Plugins overwrite each other.
This is the one that costs real rankings. Two plugins that both write canonical tags will both write canonical tags, and the page ends up with two, so Google picks one or ignores both. Page builders do the same to meta descriptions, an ecommerce plugin adds its own product markup on top of the schema your SEO plugin already output, and a caching plugin serves a version of the page from before the last fix. Nobody notices, because the admin screen shows a green light and the page looks correct in a browser. It's only visible in the source.
Themes load everything, everywhere.
Multipurpose themes ship with sliders, galleries, portfolio modules and icon libraries, and most load their CSS and JavaScript on every page whether or not the page uses them. A contact page ends up carrying a slider script and three font files it has no use for. That's a speed problem and, on mobile, a conversion problem.
The SEO plugin was installed and never configured.
Installing Yoast or Rank Math does almost nothing on its own. The defaults leave archives indexable, leave title templates generic, and set no canonical strategy. Most sites we look at have the plugin, the green lights and no configuration underneath. The plugin is a set of controls. Someone still has to use them.
The order to check things in
- Count what's indexed against what should be. Search Console's page indexing report, then a
site:search. If the two numbers are wildly apart, you've found the problem before you've opened the site. - Look at what those extra URLs are. Nine times in ten it's tags, attachments, paginated archives or search result pages.
- View the source of one important page and search it for
canonical, then fordescription. More than one of either means a plugin conflict. - Turn plugins off one at a time on a staging copy and watch what changes in the source. Never on the live site.
- Then, and only then, look at speed. Fixing speed on pages that shouldn't exist is wasted work.
Most of this is standard technical SEO applied to a platform with particular habits.
How we run it
We audit the whole install
Themes, plugins, indexed URLs, page source, host and PHP version. In writing, with the risky parts flagged.
We fix indexation first
Decide what belongs in the index, then remove the rest properly with redirects where they're warranted.
We clean the build
Plugin conflicts resolved, unused assets stopped, templates trimmed, tested on staging before anything goes live.
We keep it maintained
Updates break things, so someone should be watching. That can be us or you, but it should be somebody.
Who this suits, and who it doesn't
It suits WordPress sites that have been running a few years, sites with 20 plugins, and anyone who inherited a build from a developer who has moved on.
It's a poor fit if the site is so far gone that a rebuild costs less than the repairs. We'll say so, and WordPress design is the conversation instead.
Why clients stay
Developers, not plugin installers.
We read the theme, we read the source, and we fix in code where a setting won't do it. Same team builds the sites.
We host WordPress too.
Australian hosting in a Sydney data centre, so when the problem is the server rather than the site we're not stuck emailing someone offshore. See web hosting.
"Can't a plugin do all this?"
A plugin gives you the settings. It doesn't decide whether your tag archives deserve to be indexed, and it can't tell that your page builder is overwriting the meta descriptions it just wrote.