The WordPress Site Looked Simple. Then I Logged In.

A big part of the work at r2ware is inheriting WordPress sites I didn't build. A client wants to migrate off WordPress, or move hosts, or just understand what they're paying to maintain. Before I can quote any of that honestly, I have to answer a deceptively hard question: what is actually in here?

The front end tells you almost nothing. A site can look like five tidy pages and be hiding a custom post type, a page builder, a dozen plugins, and, as you'll see in a minute, a few hundred pages of injected spam. So I built an AI skill called wpdoc to document a WordPress site for me, top to bottom, in a few minutes. It works well and has saved me a ton of time not just by generating quotes quickly but with the resulting work being estimated accurately.

What I mean by "documenting" a WordPress site

wpdoc works from two angles:

1. The public site. It crawls the live HTML the way a visitor (or Google) sees it: pages, forms, the frontend JavaScript and CSS libraries, animations, response headers.
2. The admin. It logs into /wp-admin through a real browser session (Playwright) and reads what only an admin can see: the full plugin list, themes, users, media library, site health, and the true content counts.

Then it writes everything to a wpdocs/ folder as plain Markdown:

• site-overview.md
• plugins.md
• theme.md
• pages-and-posts.md
• media.md
• forms.md
• frontend-libraries.md
• headers.md
• Plus the raw crawl and screenshots.

There is no dashboard, just the LLM and an agent. You get a folder of documentation you can read, diff, and hand to a client.

Here's why that matters, told through two real sites. I've anonymized both, but the shape of the data is exactly what I got back.

Example one: the site that was exactly what it looked like

The first was a commercial real estate site I'll call Brightwater Crossing. The site-overview.md produced summarized it in one screen:

WordPress version: 6.9.4
Hosting: GoDaddy Managed WordPress (WPaaS)
CDN / WAF: Cloudflare
Active theme: Brightwater (custom theme, no parent)
Plugins: 5 active, 0 inactive, 0 pending updates.
Overall complexity: Simple.

That's a migration scope in a paragraph. Five real pages, one custom post type (12 entries managed with ACF), five well-known plugins, a hand-built theme using classic templates, no page builder. wpdoc even flagged the small stuff a human reviewer would miss on a busy day: a BugHerd QA widget still loading on every public page, search-engine indexing switched off, no Open Graph tags. None of it alarming. All of it useful to know before you write a number on a proposal.

This is the boring, valuable outcome: confidence. I could scope that migration the same afternoon.

Example two: the site on the struggle-bus

The second looked even simpler from the outside: a single-page winery and events site I'll call Hollowbrook Estate. One scrolling homepage, a gallery, a contact form. You could glance at it and quote a one-day move.

Then wpdoc logged into the admin, and the overview came back like this:

Security note: Only 1 of the 6 published pages is the legitimate site page (Home). The remaining 5 published pages and all 222 posts are spam / SEO-injection content added by a compromised "admin" account. Multiple obfuscated fake plugins are also present and active.

Two hundred and twenty-two posts on a site that displays zero blog posts to visitors. Categories like "Online dating," "Mail Order Brides," "Webcam." Five of the six "published" pages were injected essay-mill spam. The content was invisible on the front end and quietly feeding an SEO-poisoning scheme through the client's domain.

The plugin inventory was worse, and this is the part I find genuinely useful about reading a full admin dump:

Security note: 16 of the active plugins have nonsense names (Abywanuf, Achakovu, Achelug, Achicakho, …) with fabricated descriptions and version numbers. These are malicious / obfuscated plugins installed as part of a site compromise.

Sixteen fake plugins with randomly generated names and authors, sitting active alongside the real ones (Yoast, Contact Form 7, ACF). There was also a second admin account that wasn't the client. None of this is visible from the homepage. You only find it by logging in and actually looking, which even when you're doing everything right, it's so much nicer to have all that info documented automatically and consistently.

That site didn't need a migration quote. It needed an incident-response conversation. wpdoc turned a job I would have underquoted and inherited the mess on into a clear, documented finding I could bring to the client the same day.

Why I bother automating this

The point of automating it isn't to save myself the manual labor. It's that when documenting a site costs five minutes, I do it every time: on every inherited site, before every quote, as a standard first step instead of a someday-when-I-have-time chore. The output is consistent, it's diff-able, and it's already in a format I can hand to a client or drop into a migration plan.

That's the same idea behind everything I build at r2ware: take the thing that's important-but-tedious, make it nearly free to do, and watch how much more often it actually gets done. Documentation isn't busywork. Done early, it's the cheapest risk assessment you'll ever run, and occasionally it's the thing that catches 222 spam posts before they become your problem.

If you're about to migrate, rebuild, or take over a WordPress site you didn't write, document it first. Look in the admin, not just at the homepage. You'd be surprised what's hiding one login away.

The skill itself

Here's the full wpdoc skill if you want to read it or adapt it for your own work.

In case you're not familiar with running skills, they're straightforward for anyone familiar with AI coding agents and/or the command line. Review the Claude Code skills docs and the OpenCode skills docs for more info.