toolkit

Scenario · Before you touch a site

What is this site running?

“What is this site running?” Asked before quoting, planning, or touching anything.

Before quoting on work, planning a migration, or touching anything on a site nobody here built, the first fact that's actually worth knowing is what it's running on — which platform, which theme, which page builder, what's caching it. This reads all of that from the outside with no login required, and is careful to report what it can't see as genuinely unknown rather than confirmed absent, because a plugin or setting invisible to an outside check is still very real.

What to ask for

WordPress inspectorRead-only WordPress site inspector — fetches a URL and reports what the site is running before you touch it: whether it is WordPress at all, the WP and PHP versions, web server and managed host, active theme and child theme, the page builder (Divi 4 vs 5, Elementor, Beaver Builder, WPBakery, Bricks, Oxygen, Gutenberg), the plugins visible from outside, the caching and CDN layer, and externally-visible security notes — into a DETECTED / LIKELY / NOT WORDPRESS verdict plus an HTML report.

See it work

A real run of WordPress inspector:

WordPress inspector · wordpress-inspector — inspecting https://toolkit-tests.pages.dev/wp/wp-gold.html …

DETECTED — https://toolkit-tests.pages.dev/wp/wp-gold
  WP version    6.5.2
  Server        cloudflare
  Theme         twentytwentyfour 6.5.2
  Plugins       2 visible
  Caching       WP Rocket
  CDN           Cloudflare

  report: ./out/wordpress-inspector-wordpress-inspector.html
  text:   ./out/wordpress-inspector-wordpress-inspector.txt

The captured report, exactly as a run hands it to a client —open the full report ↗

The first question on any site you didn’t build, and the fastest to answer from outside: whether it’s WordPress at all, which version, which theme, which page builder (Divi 4 vs 5, Elementor, Beaver Builder, WPBakery, Bricks, Oxygen, Gutenberg), the caching/CDN layer, and whatever plugins are visible from the outside.

  1. Run the stack inspection before planning any change — quoting work, scoping a migration, or just understanding what you’ve been handed.
  2. Record the detected platform, theme, builder, plugin list and version evidence exactly as reported, including the confidence level (DETECTED vs LIKELY vs NOT WORDPRESS).
  3. Treat anything the report doesn’t surface as unknown, never as confirmed absent — a plugin with no front-end footprint is real and simply invisible to a check that never logs in.
  4. Use the inventory to pick the right owner and the right change plan, then re-check the affected public page after any approved work to confirm the stack still matches what you expect.

Absence of evidence is not evidence of absence

The one discipline this scenario exists to enforce: a clean report says what’s visible from outside, not what’s true. Anything requiring a login — most plugin configuration, most of what actually matters for a real migration plan — stays a question mark until someone with access answers it.

What this does not cover

Anything that needs a login. No login, no writes, no crawling — so a plugin or a configuration choice that leaves no trace in the delivered HTML is invisible to it, and absence of evidence is never treated as proof of absence.

← All scenarios