WordPress

WordPress, and the buttons an audit cannot see

Most of what goes wrong when auditing WordPress is not WordPress. It is the page builder on top of it naming things its own way, and a checker that only learned one vocabulary.

Ten booking buttons, reported as none

A three-branch Manchester barbershop was told its site had no call to action. The site has ten booking buttons — “Book at Tib St”, “Book at Newton St”, “Book at Prestwich”, and six more in the footer.

Every one of them is class="et_pb_button barber-book-now", which is what Divi emits. The check was looking for the class btn as a substring and button as an exact class name. et_pb_button contains neither: it has no btn in it, and it is not .button. So the selector matched Bootstrap and very little else.

That is not an edge case. Divi, Elementor (elementor-button), WordPress blocks (wp-block-button__link) and Squarespace (sqs-block-button-element) are between them most of the market this product serves. The check now matches either spelling as a substring, case-insensitively, plus the elements that are buttons whatever anyone calls them.

Your sitemap is probably not where the checker looks

WordPress has published its own sitemap at /wp-sitemap.xml since version 5.5. A checker that only tries /sitemap.xml and /sitemap_index.xml will report a missing sitemap on a site that has one.

Related, and more important: this engine refuses to report “no sitemap found” when it could not read robots.txt at all. Not being able to look is different from looking and finding nothing, and a report that confuses the two is telling you about its own network rather than about your site.

An exposed installer is not a website

A domain serving wp-admin/install.php is a WordPress installation waiting for somebody to claim it — and anyone who reaches it first can. The engine refuses to audit it and says so plainly, because a fifteen-point report about heading structure is the wrong thing to hand somebody in that position.

What actually turns up on WordPress sites

In the audits run so far, the findings that recur on WordPress are rarely exotic. They are: contact forms with no labels on the fields, no review or rating markup for a search engine to read, no accessibility statement, and missing email authentication records on the domain. None of those are plugin problems. All of them are ten-minute jobs.

The plugin question

This engine does not enumerate your plugins or tell you which ones are out of date. It reads what your pages send to a visitor, from outside, without logging in — so it can see a JavaScript library with a known vulnerability where the version is stated in the file, and it says nothing about the rest. A tool that claims a plugin inventory from the outside is guessing from fingerprints, and a wrong guess about your security is worse than no guess.

Questions people ask

Do you need a login to audit my WordPress site?

No, and you should not give one. Every check reads what your pages already send to any visitor. Nothing is submitted, nothing is written, and no form on your site is filled in — posting to a contact form would put a fake enquiry in your inbox.

Will the audit tell me which plugins to remove?

No. Plugins cannot be reliably inventoried from outside a site, and a list assembled from fingerprints would be a guess presented as fact. Where a JavaScript library states its own version and every release that version could mean is known-vulnerable, that is reported. Where the version is ambiguous, it is not.

My site is on Divi. Does that change what you check?

It changes how some checks are written, not what is checked. Divi names its buttons et_pb_button, its sections et_pb_section and so on, and a check that only knows Bootstrap’s vocabulary will report things as missing that are plainly on the page. Those spellings are handled.