How to Run a Technical SEO Audit on a WordPress Site
Technical SEO is the part of search optimisation that nobody sees and everybody feels. A site can have excellent content and a strong backlink profile and still underperform because two plugins are both writing canonical tags, or because five stylesheets have been returning 404 since the last redesign.
WordPress makes these problems unusually easy to create. Every plugin can add to the <head>. Every theme can override what the plugin did. The result is sites where nobody is quite sure what is being output, and where the answer only appears when you look at the raw HTML.
This is the audit we run, and the order we run it in.
Step One: Can Google Actually Reach the Page?
Everything else is irrelevant if crawling is blocked. Four checks, in this order:
robots.txt. Fetch it directly. Look for strayDisallowrules that belong to no user-agent group — a blank line in the wrong place orphans every rule beneath it, and the directives silently stop applying.- The
robotsmeta tag. Check the rendered HTML, not the plugin settings. Sites frequently carry a leftovernoindexfrom a staging environment. - HTTP status codes. A missing page must return 404, not 200 with an empty template. Soft 404s waste crawl budget and confuse indexing.
- Redirect consistency.
http://,https://,www.and non-wwwmust all resolve to one canonical host in a single hop.
The last one deserves attention. A redirect chain of three hops is not fatal, but it wastes crawl budget on every request and slows real users on mobile connections.
Step Two: Look for Duplicate Head Tags
This is where WordPress sites most often go wrong, and it is nearly invisible unless you look. When an SEO plugin and a theme both output metadata, you end up with two canonical tags, two sets of Open Graph properties, two robots directives.
Fetch the page HTML and count. If you find two canonical tags pointing at the same URL, the damage is limited but the signal is sloppy. If they point at different URLs, Google picks one — possibly not the one you wanted.
Open Graph duplication is worse in a different way. Social platforms do not all resolve conflicts the same way, so a page with two og:image values may share correctly on one network and show a blank placeholder on another. We have seen sites sharing a 1,500-byte default avatar because a plugin’s fallback image won the conflict.
The fix is always the same: pick one source of truth and disable the other. Never leave both running on the assumption that the better one wins.
Step Three: Measure, Do Not Guess, Performance
Core Web Vitals are a genuine ranking factor, though a modest one. More importantly they are a genuine user experience factor, and the two things move together.
The three metrics and what usually causes them to fail on WordPress:
| Metric | Good | Usual WordPress cause |
|---|---|---|
| LCP (Largest Contentful Paint) | under 2.5s | Slow server response, unoptimised hero image, render-blocking CSS |
| INP (Interaction to Next Paint) | under 200ms | Heavy JavaScript from page builders and chat widgets |
| CLS (Cumulative Layout Shift) | under 0.1 | Images without width and height, late-loading fonts, cookie banners |
Three fixes cover most sites. Set explicit dimensions on every image, including the logo — it is the most commonly missed one. Add loading="lazy" to everything below the fold. And audit what is actually being loaded: we regularly find themes still requesting ie7.css and ie8.css in 2026, alongside stylesheets that were deleted in a redesign and now return 404 on every single page load.
That last category is the easiest win in technical SEO. A 404 on a stylesheet costs a full round trip and delivers nothing.
Step Four: Check What the Sitemap Actually Contains
A sitemap that lists pages you do not want indexed, or omits pages you do, sends conflicting signals. Fetch /sitemap.xml and verify it returns valid XML, that lastmod dates are real rather than today’s date on every entry, and that the URLs match your canonical format exactly — including trailing slashes.
Also confirm the sitemap regenerates when you publish. On low-traffic sites where WP-Cron rarely fires, sitemaps can go stale for weeks without anyone noticing.
Step Five: Validate Structured Data Against What Is Visible
Extract every application/ld+json block and parse it. Two failure modes are common: JSON that does not parse at all because a quote was not escaped, and markup describing content that does not appear on the page.
The second is a guidelines violation. If your FAQPage schema lists six questions and the page shows four, you risk losing rich results entirely. Mark up what is there, nothing more.
While you are in there, check for the obvious gaps. A site with a visible FAQ section and no FAQPage markup is leaving free search real estate on the table. So is a pricing page with no Offer markup.
Step Six: Audit the Multilingual Setup, If There Is One
Multilingual WordPress sites fail in specific, repeatable ways. Two separate plugins emitting two different hreflang formats for the same URL. Language codes that do not match the actual content. Missing x-default. Translated pages that canonicalise back to the English original, telling Google to ignore them.
The rule is simple: every language version must reference every other version, including itself, and the set must be identical in both directions. A one-way hreflang reference is ignored.
Step Seven: Check the Things Only a Crawl Reveals
Some problems only appear at scale. Orphan pages with no internal links pointing at them. Paginated archives that repeat the same title tag forty times. Tag archives with one post each, creating thin duplicate content. Parameter URLs generating infinite crawl paths.
For a site under a few hundred pages, a careful manual pass through the sitemap catches most of it. Beyond that, a proper crawler pays for itself in the first session.
What We Find Most Often
Across the audits we run, the same handful of issues account for the majority of findings:
- Duplicate meta tags from plugin and theme conflict — present on roughly half the sites we look at
- Stylesheets or scripts returning 404, left behind by a redesign
- Missing structured data on pages that already contain the content it would describe
- Images without dimensions, causing avoidable layout shift
- A
viewportmeta tag withuser-scalable=no, an automatic accessibility failure - Meta keywords tags carrying fifty or more terms, a legacy spam signal that costs page weight and buys nothing
None of these are difficult to fix. All of them are easy to miss, because none of them are visible on the rendered page.
Frequently Asked Questions
How often should a technical audit be run?
A full audit twice a year, plus a short pass after any redesign, theme change or major plugin update. Those three events cause most new technical problems.
Do I need a paid crawler?
For a site under about 200 pages, no. Fetching the HTML directly and checking the head tags, headings, links and structured data by hand is entirely practical and often more revealing, because you see exactly what is being output rather than a tool’s summary.
Is page speed really a ranking factor?
Yes, but a modest one compared to relevance and authority. Its bigger effect is on conversion. A site that loads in one second converts measurably better than the same site at four seconds, and that difference usually dwarfs the ranking impact.
Should I worry about two canonical tags if they point at the same URL?
It is unlikely to cause direct harm, but it signals that two systems are fighting over your head section. Today they agree; after the next plugin update they may not. Fix the underlying conflict rather than the symptom.
What is the fastest technical fix with the biggest effect?
Removing resources that return 404. They are pure waste — every page load pays for them and nothing is delivered. We have removed seven dead stylesheet requests from a single site in ten minutes.
Does WordPress have inherent SEO disadvantages?
No. WordPress powers a large share of the top-ranking sites on the web. Its problems come from plugin accumulation and abandoned theme code, not from the platform itself.
The Bottom Line
Technical SEO is not glamorous and it does not produce dramatic before-and-after screenshots. What it does is remove the friction that stops good content from performing. Most sites do not need a rebuild — they need someone to read the actual HTML and fix the six things that have accumulated there.
If you would rather not do it yourself, our SEO opportunity analysis covers exactly this ground, and the findings feed directly into our on-page work. For reference material, Google’s crawling and indexing documentation and the Core Web Vitals guide are the authoritative sources.