field note
first published 2026-10-10
WordPress SEO consultant: what breaks on WordPress, and why it's rarely WordPress
What a WordPress SEO consultant actually finds — the server in front, the builder, the plugins, the edge — with the readouts from my case files, what I ship inside WordPress, and how to tell a consultant from an agency, a freelancer or a plugin.
1,759 words · 8 min read · technical seo
Most of the WordPress sites I am asked to look at arrive with a diagnosis already attached: WordPress is slow, WordPress is bloated, WordPress is bad for search. Then I read the server and the diagnosis changes. In nineteen years I have not found a ranking problem caused by WordPress itself. I have found a great many caused by what was bolted on to it, what was put in front of it, and what was never configured at all.
The distinction matters because it decides who you should hire and what they need to be allowed to touch. This is what a WordPress SEO consultant actually finds, with the numbers from my case files, and what the fix looks like when it ships.
The platform is neutral. The layers around it are not.
WordPress on its own is a short list of promises: a URL maps to a post, a theme renders it, a plugin can change almost anything. Each promise is also a door. The problems I find come through four of them, in a fairly consistent order.
The server in front
A US coaching practice, Small Business Coach Associates, got a report from a ranking tool saying its sitemap was missing, with three remedies attached. All three were already switched on. The sitemap was fine. The tool had knocked on the bare domain, and the SEO plugin's sitemap redirect only fires on the canonical host; WordPress's own canonical redirect never rescues a path that 404s. Nothing at the server level canonicalised the host, so the apex sitemap really was a 404 for anything that started there. The fix was one server-level 301, placed ahead of the WordPress block so it wins before the application runs. Afterwards, eight combinations of host, scheme and user agent all landed on the sitemap index with a 200. The three prescribed fixes stayed untouched, because none of them was the problem.
A UK tile retailer trading online only, on a WooCommerce store, came in with its head terms on page two, 7.1 seconds to paint on a phone and a server response of 2.2 seconds. No page cache had ever been configured; the server rendered every request from scratch. Three plugins were writing notices with full backtraces on every product call, a few kilobytes each, thousands of times a day, into an error log that had reached 113 MB and was still growing. Bringing the cache up and silencing the notices at source took the server response from 2.2 s to 47 ms. The front end was not touched.
The builder
Page builders are where most of the duplicate content on WordPress comes from, and nobody notices because the builder's own pages look fine. The same tile retailer had 196 reusable-block pages published, indexable and in the sitemap: a shadow site of duplicates the builder had left public, with the cart and checkout in the sitemap for company. Hiding them from the public and the crawlers was the easy part. Two weeks later the builder's preview broke for editors, because the rule that hid the blocks also hid their previews behind a redirect. The fix was a capability check, so editors keep their previews, uncached and noindexed, and the public and the crawlers keep seeing nothing. The regression test for it is still in the repository.
A private dental practice in Leeds had three h1s on its homepage, all from the builder. Two of them became h2s by editing the builder's JSON losslessly, with a backup kept. The site went from 74 to 99 on the Agent-Ready Grader that runs on this site, and the heading count was the smallest of its three findings.
A multi-branch auto locksmith on a page-builder site was rebuilt as a bespoke theme without losing a URL. The 238-URL inventory was frozen before a line of theme code was written, and the cutover was verified 238 of 238: every old URL fetched, every one answering.
The plugins
Plugins are where WordPress earned its reputation, and the reputation is deserved in exactly one sense: a plugin can do anything, including the wrong thing on every page load. The three plugins filling the tile retailer's error log were the mild case. On one of three small-business sites I did structured data for this summer, a plugin stored an array option as a JSON string, which broke Open Graph site-wide the moment it was written the obvious way.
The severe case is not a search finding at all. During the locksmith rebuild, the live site was found minting administrators. Two doors were open: public registration switched on with the default role set to administrator, and a nulled automation plugin with a known SQL-injection route. Six rogue admins removed, registration closed, sessions destroyed, four nulled plugins deleted, core verified clean, and the nine sibling sites on the same box checked and found untouched, all on the same day. A nulled plugin is not a bargain. It is a door with the lock removed.
The edge
The newest layer sits in front of everything above: the hosting firewall, the CDN, the bot-management product. The dental practice's largest finding was there. The edge was returning 403 to user-agent-spoofed Googlebot and Bingbot while the real, verified crawlers got through. Real search rankings were unaffected; agents and spoofed checks were being refused. That is a true positive with a benign cause, and it is the shape of most edge findings in 2026: a security rule written for scrapers that now decides whether the AI answer engines can read you at all. It was disabled with the trade-off written down, a live and revertable security downgrade bought for the score.
On Mowers Online, a WooCommerce store, roughly 45% of August's sessions were a headless-Chrome farm that never bought anything, and the cache in front of the site was pinning a broken build for up to a year because the optimiser's bundle filenames were not content-keyed. The fix ran through edge rules and cache policy. WordPress was not involved.
What I ship on a WordPress site
The diagnosis above is the half most audits get right. The other half is shipping it inside WordPress without making the next person's life worse, and that is where a consultant who writes the code earns the fee.
The configuration in front of WordPress gets the jobs it should have had all along: the host canonical, the redirect layer, the cache policy. A UK data-cabling contractor had redirects living in two layers that both fired, with a prefix-matched server rule hijacking every subpath before the plugin's exact-match table could see it. Reconciling them was a configuration change, not another plugin.
Inside WordPress the fixes are small, owned and reversible. Two small plugins shipped product schema and a trust badge on Mowers Online. An owned plugin injects an @id-linked structured-data graph on sites where the builder's output was a scatter of unrelated blocks; that is how three small businesses on Elementor, Framer and Beaver Builder reached zero validator errors and zero warnings on every page. Every file I touch has a backup, and the record says how to put it back.
The theme comes last, and only when the measurements say the theme is the cause. The tile retailer's 2.2 s to 47 ms came from the server, not the templates. The locksmith's rebuild happened because the brief asked for a design worth the phone call, not because the builder was slow.
Then the readouts: server timing, the sitemap crawl, Search Console, the log, read again after the change and written in plain words.
Consultant, agency, freelancer or "WordPress SEO services"
The phrase people type varies more than the thing they need, so here is the honest comparison.
A WordPress SEO agency sells a team, a process and a monthly deck. The audit is often good. The implementation goes to your developer's queue, or to the agency's junior with the plugin settings page open, and the server-side findings, which are most of the findings above, never get done because nobody in the chain has root.
A freelancer sells hours, usually inside the WordPress admin, usually through the plugin. That reaches the title tags and the sitemap toggle. It does not reach the host canonical, the cache layer, the error log or the edge rule.
A "WordPress SEO service" bought as a product is a plugin configuration with a report attached.
What I do is narrower and deeper. Read the instruments: the logs, Search Console, server timing, a full crawl. Name the cause with the evidence beside it. Ship the fix in the layer where it belongs. Read the instruments again. One person, from the first fetch to the last commit. If the cause turns out to be a plugin setting, that is in my first reply, and it does not cost you an engagement.
Five checks before you hire anyone
Most of the above can be found in half an hour with nothing you have to pay for.
- Fetch your sitemap on the bare domain and on www, with and without https. All four should end on the same sitemap index with a 200. If one of them 404s, the server in front of WordPress is not doing its job.
- View the source of your homepage and count the h1 tags. One is the answer. More than one is the builder.
- Open the sitemap your SEO plugin generates and look for post types you did not know were public: reusable blocks, templates, the cart, the checkout.
- Find your error log and look at its size. If it grows by megabytes a day, something is writing on every request, and every request is paying for it.
- Time the server's response to a product or category page with the cache bypassed. Over a second means the cause is on the server, and so is the fix.
If any of those fails, the fix lives in a layer your SEO plugin cannot reach.
Where WordPress genuinely is the problem
Honesty cuts both ways. WordPress is the right platform for most of the sites I see running on it, and the wrong one for a few: catalogues that have outgrown WooCommerce's query model, and sites whose builder is simulating a content model the platform does not have. In those cases I say so, along with what a migration would cost in URLs, which is the only cost search cares about.
Everything else is a layer. Layers can be fixed, and the fix can be read back from the same instruments that found the fault.
asked straight — answered straight
01Do you work on WooCommerce as well as WordPress?
Yes. The UK tile retailer in the case files is a WooCommerce store and so is Mowers Online. The accessibility engine I ship on WordPress.org scans the WooCommerce checkout with a real cart populated across three generations of Woo markup, so I know that markup better than I would like to.
02Which WordPress SEO plugin should I use?
Whichever one your team already understands. I have not yet met a site whose problem was the choice of SEO plugin. I have met many where the plugin was configured for a host the site no longer used, or was being asked to do a job the server should do. I have shipped two plugins to WordPress.org, so I know what a plugin can reach and what it cannot.
03Can you make a WordPress site fast without rebuilding the theme?
Usually. The tile retailer's server response went from 2.2 seconds to 47 milliseconds without touching the front end: a page cache that had never been configured, and three plugins silenced at source. A theme rebuild comes later, if at all, and only when the measurements say the theme is the cause.
04Should I hire a WordPress SEO agency, a freelancer or a consultant?
It depends what needs doing. An agency sells a team and a monthly report. A freelancer sells hours, usually inside the admin. I sell the diagnosis and the fix as one thing, in your admin and on your server, with every change reversible and written down. If the problem turns out to be small, I say so in the first reply, before you pay for anything.
05What access do you need?
Administrator on the site and, for most findings, the hosting panel or the server itself: the cache, the configuration in front of WordPress, the error log. I read before I touch anything, keep a backup of every file I change, and leave a written record of each change and how to revert it.
next step — seo consultant
SEO consultant who ships.
Nineteen years of search, shipped by the person who diagnosed it. Send a brief — a few lines about the site, the problem and the evidence you have — and the reply is a straight read on fit and shape, from the person who does the work.
no forms · no funnels · jamie@jamiemckaye.com
written by
Technical SEO consultant and full-stack developer in Hersham, Surrey, in practice since 2007. One person, no handoffs: the audits, the code and the writing come from the same pair of hands. This site is the working proof — it grades itself on the same instrument it runs for clients.