WordPress audit: the scan that tells you what to change, then checks that it is fixed

What a WordPress audit should give you

If you are looking for a WordPress audit — a WordPress site audit, a security audit, a speed audit — you probably do not need a definition. You want to know what is wrong on your site, and above all what to do next. Many guides on the topic handle the first half and skip the second.

They list thirty things to check and give advice that is true but generic — “optimize your images,” “install a caching plugin” — and stop there. You close the tab knowing what to look at, without knowing what is actually broken on your site or how to fix it precisely. That is the gap this page fills. “Optimize your images” does not help. “Open Imagify, turn on WebP conversion and Display images in Next-Gen format on the site, then rescan” does.

The loop has three steps, and it is what this whole page is about:

1. Diagnosis — the scan finds the problems and ranks them by severity.
2. Fix — for each one, the exact WordPress plugin or setting to change.
3. Proof — a rescan that shows the score before and after. Without it, you never know whether you fixed the problem or just moved it.

What the scan checks, and a quick win in each dimension

Six dimensions. The free audit gives you the score for each one plus the five priority fixes. For each dimension, here is a high-return fix that comes up often — the kind you can do this weekend.

Many audits stop at a list like this one. The rest of this page goes further: the exact WordPress change, issue by issue.

How the score is calculated, and what it does not tell you

The question comes up every time — where does this number come from? — so here is the full answer.

Each dimension starts at 100 points. Each check that warns or fails deducts a fixed number of points, written in the engine's code. A warning costs 3 to 20 points: most cost between 3 and 8, and a slow server response is the exception at 12 or 20. A fail costs 8 to 30. Lines reported as information cost nothing, except three minor security headers that cost 2 or 3 points each when missing. A dimension never goes below 0. The overall score is the average of the dimensions, rounded. If the site does not run WordPress, the WordPress dimension is skipped and the average uses five dimensions.

In practice, an overall 68 can hide a 100 in one dimension and a 32 in another. That is exactly what the real example below shows. The overall score reassures or worries you; the dimension scores tell you where to dig.

A score is not a Google ranking

No score out of 100 — ours or PageSpeed Insights' — is a ranking factor. Google's Core Web Vitals are thresholds measured on real visitors: the largest content should render within 2.5 seconds (LCP), the page should respond to interactions within 200 milliseconds (INP), and layout shift should stay at 0.1 or less (CLS), measured at the 75th percentile of page loads, according to web.dev. Going from 82 to 87 by polishing warnings earns you nothing in search. Fixing a failed indexing check can.

Core Web Vitals: use PageSpeed Insights for those

Know this before you read your result: this scan does not measure the Core Web Vitals. It reads your HTML and your server's responses without rendering the page in a browser, so it has no LCP, INP or CLS figures to give you. What it does measure are the usual WordPress causes behind poor vitals: slow server response, images without dimensions, render-blocking CSS and scripts, heavy third-party code. For the vitals themselves, run your URL through PageSpeed Insights, which shows lab data and, when Google has enough traffic data for your page, real-user data from the Chrome UX Report. If your site is verified in Google Search Console, its Core Web Vitals report groups your URLs by status.

What an external audit sees, and what it does not

The engine reads your site from the outside, with no access to the dashboard. That is a choice — nothing to install, nothing to connect — and it comes with a trade-off worth stating plainly.

In other words, the scanner sees what Googlebot and an attacker see — and that is precisely what costs you rankings or exposes you. What it cannot see needs your own eyes in the dashboard, or a server-side security plugin such as Wordfence. When a point depends on admin access, this page says so rather than padding the check count.

A seventh layer most audits skip: whether AI assistants can find and cite you

Some of your visitors now reach you through an answer in ChatGPT, Claude, Perplexity or Google rather than through a list of links. Being cited in those answers is sometimes called GEO, for generative engine optimization, and most WordPress audits do not look at it yet.

To be upfront: of the points below, only hreflang is checked automatically by the engine (SEO dimension). The robots.txt check only raises an alarm when the whole site is blocked for all bots or for Googlebot; a block aimed at AI crawlers is left alone, because it can be a deliberate choice. The rest takes about thirty seconds each to check by hand. Here is how, with the exact command.

Crawler roles as documented by OpenAI, Anthropic, Perplexity and Google, which states that Google-Extended “does not impact a site's inclusion in Google Search.” The llms.txt proposal is at llmstxt.org.

A word on WordPress specifically. The SEO plugin you already use — Yoast SEO, Rank Math, SEOPress — outputs the structured data and dates; the byline and the author page come from your theme. An llms.txt file goes at the root of the site: a text file, nothing more. Crawler access is set in the virtual robots.txt WordPress generates, or in your SEO plugin's robots.txt editor.

The WordPress action plan: exactly what to change

This is where this page parts ways with the rest. A scanner that says “improve your TTFB” leaves you searching for two hours. Here, for common failures, is the specific change — the plugin, the option, the setting. The IDs in code are the check IDs in your report, so you can match each row to your scan; the point cost comes straight from the engine's code.

The last column is my own judgment, stated as such: an estimate of effort and gain based on making these fixes on our own sites, not a figure produced by the engine. Use it to decide when everything is red: first what takes ten minutes and pays off, then, on a quiet day, what takes two hours and hardens the site without moving the score much.

The €9.90 full report goes through all 81 checks with the measured value and the recommendation for each, plus the PDF export. The free audit gives you the five priority fixes: often enough for a first weekend. The order I follow on our own sites: page cache and WebP on Saturday morning (high gain, low effort), the REST API user list right after, then render-blocking CSS and JavaScript when there is time to retest the pages.

What the output looks like on a real site

Rather than a polished mockup, here is the real scan of mythologiste.com from July 16, 2026, a WooCommerce store we host ourselves. Its flaws are ours, and I am not going to dress them up.

The contrast is the part that matters: 100/100 on SEO, 32/100 on performance, same site, same moment. The SEO plugin does its job — title, meta description, canonical, sitemap, schema, all clean. It says nothing about performance or security, because an SEO plugin does not look at them. It is a common misunderstanding among WordPress site owners: “I have Yoast, so my site is fine.”

The proof: rescan after each fix

Fixing without checking is working blind. A real example: on mythologiste.com, turning on page caching to bring the server response time down also turned off WordPress's native lazy loading. The performance score went up on one line, and a new failure appeared on another. Without a rescan, we would never have noticed.

The method is plain and reliable:

1. Note your starting score for each dimension (the free audit is enough).
2. Fix one issue at a time, starting with the failures.
3. Rescan the same URL. Did the score move the right way? Keep the change. Did it not move, or did another issue appear? You know right away what to adjust.

For the pages that matter, make the rescan a monthly habit, because a WordPress site degrades on its own: a theme update brings back JPEG images, a plugin adds a blocking script, a migration turns “Discourage search engines” back on. The Pro plan (€29/month, account required) rescans your sites daily or weekly and emails you when a score drops. For a handful of pages, the free manual rescan already does most of the work.

Which tool for which job

This scanner replaces neither your SEO plugin, nor PageSpeed Insights, nor a consultant. It covers a specific need; here is which one, and what it cannot do.

Our limits, plainly. The engine analyzes one URL at a time, not the whole site: it will not see your orphan pages, your click depth or your duplicate content. It knows nothing about your backlinks and does not judge whether your content answers the search intent. A sensible order: the scan first, because it takes a minute and catches the mechanical problems; a side-by-side comparison with a competitor next; then a human, if the business stakes justify it.

What we actually find: 21 WordPress sites through the scanner

Method. On July 16, 2026, I ran 21 French-language WordPress sites through this engine: WordPress and SEO blogs, agency sites, hosting company sites. It is a flattering sample — web professionals, not a small business site left untouched since 2019 — and a French-language one, so a sample of English-language sites could look different. Keep both in mind.

• Median overall score: 79/100 (min 65, max 87). Nobody reached 90, including people who do this for a living.
• 15 of 21 sites serve no image in WebP or AVIF. None at all. Worst of the batch: a page loading 293 images, every one of them JPEG or PNG.
• 6 of the 11 sites whose REST API responds publish their user list at /wp-json/wp/v2/users — up to 10 usernames in clear text, the first half of what a password-guessing attack needs.
• 16 of 21 sites have no Content-Security-Policy, and 9 of 21 have no HSTS.
• Median server response time: 171 ms; only 3 of 21 sites exceed 600 ms. In this sample, images are the widespread problem, not servers.

Two things this batch taught me. The slowest server response in the sample (1,802 ms) belongs to a site we manage ourselves. And a well-known French-language SEO site was serving, that day, the title of an Indonesian online gambling spam page (“ROYALTOGEL — Login Bandar Slot Gacor”): an injection hack invisible from the WordPress dashboard, but the first thing Google read. An external audit saw it; the dashboard did not.

Frequently asked questions