toolkit

Scenario · Before you touch a site

We've taken on a new client

A new practice signs, and nobody here has ever looked at their site.

The day a new practice signs is the one and only chance to establish what was already broken before anyone here touched anything — after that, every problem found later gets assumed to be ours. This builds that baseline: what the site runs on, what's already measuring it, how outdated or risky its plugins already are, and whether the basics even work, all captured on day one so it can be pointed to later as evidence of what actually improved.

What to ask for

Hosting & DNSHosting & DNS infra fingerprint — reads a domain's DNS, TLS, headers and RDAP and reports the backend stack: web host, nameservers, CDN/edge, email provider, SSL issuer, CMS, registrar and last-changed date.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.WP plugins & themeWordPress plugin and theme audit — takes the plugins and active theme a site exposes and checks each against the WordPress.org directory for freshness: outdated (behind latest), abandoned (long since updated), and lagging the current WordPress version.Sitemap & robotsRead-only sitemap & robots map — fetches a site's robots.txt and every sitemap it declares (or probes the common locations), follows sitemap indexes down to their children, collects every URL, and reports what is declared, what robots.txt blocks, and what is oversized, cross-host or insecure, plus a crawl-over-crawl diff.Analytics & tagsAnalytics & tag presence audit — reads a page's delivered HTML and inventories the measurement, advertising and session-replay tags firing on it: Google Tag Manager, GA4, legacy Universal Analytics, Google Ads, Meta Pixel, LinkedIn, TikTok, Microsoft Ads, Pinterest, Clarity, Hotjar, Segment, Matomo.Critical-path smoke testCritical-path smoke test across every domain at once.Provider roster checkProvider roster check — compares the people a site publishes against the roster of who should be there.

See it work

A real run of WP plugins & theme:

WP plugins & theme · wp-plugins-and-theme — https://toolkit-tests.pages.dev/wp/wp-gold.html
  detecting plugins + theme via wordpress-inspector …
  auditing 3 item(s) against the WordPress.org directory + WPScan …

FAIL — https://toolkit-tests.pages.dev/wp/wp-gold.html
  3 audited · 3 outdated · 0 abandoned · 2 vulnerable
  FAIL   contact-form-7 (plugin) — outdated: 5.9.2 → 6.1.7 (major); 2 known vulnerabilities — fixed in 6.0.6
  FAIL   wordpress-seo (plugin) — outdated: 22.0 → 28.4 (major); 6 known vulnerabilities — fixed in 28.1
  REVIEW twentytwentyfour (theme) — outdated: 1.1 → 1.6 (minor)

  playbook: local fallback

  report: ./out/wp-plugins-and-theme-wp-plugins-and-theme.html
  text:   ./out/wp-plugins-and-theme-wp-plugins-and-theme.txt

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

The one chance to establish what was already broken. Every problem found later is otherwise assumed to be ours, and without a baseline there is no way to say otherwise — nor to show, twelve months on, what improved.

  1. Read the infrastructure from outside. Hosting, nameservers, CDN, email provider, SSL issuer, registrar and when the domain last changed. This is also the list of things you will need access to, and an expiring domain or certificate found on day one is a good first win.
  2. Confirm what the roster thinks. The provider roster check compares the domain against what we believe about it. Getting this right at onboarding is what keeps the monthly fleet sweep honest later.
  3. Fingerprint the site. What it is built on, which builder, the WordPress and PHP versions, the theme, the caching. This determines which of everything else even applies.
  4. Inventory the plugins and their health. Outdated, abandoned and known-vulnerable. On an inherited WordPress site this is routinely the largest single risk and it is entirely pre-existing — which is precisely why it belongs in a baseline rather than in a surprise three months later.
  5. Map the site. Sitemap and robots, producing the URL list everything else runs against. A site whose sitemap is missing, stale or blocked is a finding in itself.
  6. Find out what is measuring it. The tag audit inventories the analytics and advertising tags currently firing — including the previous agency’s, which nobody will mention and which is still collecting.
  7. Smoke-test it. The critical-path check confirms the home page loads and the basics are present. If something is already broken, it is worth knowing before the first ticket.
  8. [manual] Write the baseline down and keep it. One document: stack, hosting, plugin risk, page count, what is measuring it, what is already broken. This is the artefact — and it dates from before we touched anything, which is its entire value.

The baseline is the deliverable

Every check here is one we run elsewhere. What makes onboarding different is the timing: run on day one these are a record of the inherited state, and run in month three they are indistinguishable from our own work. Step 8 is the step that is actually easy to skip and impossible to recreate.

What this does not cover

Access, contracts and the relationship. This is the technical baseline: what the site is, who runs it, what is measuring it, and what state it is in on the day we took it over. It cannot get you into their accounts, and it deliberately fixes nothing — the point is a record of what we inherited, before anyone changes anything and the question becomes unanswerable.

← All scenarios