Audit a WordPress site you just inherited

MaintenanceIntermediate~10 min

Before you start

A connected site with reads enabled. Some of these reads sit behind higher capabilities (listing plugins, users, and the theme), so bind the agent to a user that can see them or expect the gated sections to come back empty. No integrations needed.

Inheriting a site is the same problem every time: nobody wrote anything down, the last person is gone, and you do not know what is installed, who can still log in, or how the content is put together. Before you change a single thing, you want the lay of the land.

The whole-site content audit recipe hands you counts. This one goes a layer deeper into the things that actually bite you on a handover: who holds an account, what is running under the hood, and how the content is shaped. It is still entirely read-only.

The prompt
Give me a takeover briefing on this WordPress site. Read only, change
nothing. Start with the basics: site name, tagline, URL, and language.
Then go deeper than a content count. List the user accounts with their
roles and call out anyone who holds an administrator role. List the
installed plugins with versions and whether each is active, and the
active theme with its parent and whether it is a block theme. List the
public post types and taxonomies, and note which post types you are
allowed to write to. Finish with the counts: posts and pages by status,
and the media library by file type. Put a short "what stands out"
summary at the very top, anything that looks risky or neglected on a
site I just took over.

Why this is safe to run

Every ability behind this prompt is a read. Nothing in the set can create, edit, or delete, so the worst case on an unfamiliar site is that a section you do not have the capability for comes back empty.

That empty case is worth understanding rather than fearing. Listing plugins, users, and the theme each sits behind a higher capability than a plain content read, so the reach of this briefing tells you exactly what the agent user can and cannot see. The post-type list carries a writable flag per type, so this one answer also shows you where the agent could write later if you decided to allow it. And because it is all reads, you can run it before you trust the site enough to turn on a single write.

Already connected? You do not have to paste this. Ask your agent for the “audit an inherited site” recipe, or just tell it you took over an unfamiliar install and want the full picture, and it runs the same reads on your own site.

How it works

  1. Read the site name, tagline, URL, and language.
  2. List the user accounts with their roles and flag anyone with an admin role.
  3. List the plugins with versions and active state, and the active theme with its parent.
  4. List the post types and taxonomies, noting which types the agent may write to.
  5. Count posts by status and the media library by file type.
  6. Put a short 'what stands out' summary at the top.

Questions

Can this change anything on the site?
No. Every ability here is a read. It reports what exists and writes nothing, so it is safe to run on a site you do not fully trust yet.
Why did some sections come back empty?
Listing plugins, users, and the theme each need a higher capability than a basic content read. If the agent user does not hold them, those reads return nothing rather than erroring, and the rest of the briefing still lands.