toolkit

Scenario · Before you touch a site

Someone needs access — or needs it taken away

“Give our new marketing person access.” Or, after somebody leaves: “Remove their access.”

Granting access to a new hire is a minor inconvenience if it goes slightly wrong; taking it away from someone who's left is not, because getting that wrong leaves a former employee holding the keys to a client's analytics, ad spend and website, and the request usually arrives worded like it's routine. This inventories exactly who has access across every system in scope before anything changes, and re-checks afterward that a revoked account is actually gone rather than just removed from the one place someone thought to look.

What to ask for

WordPress REST inventoryOptional read-only WordPress REST client. Lists core facts, registered routes, installed plugins and themes, users and roles, and content totals from an authenticated WordPress site.Search Console seriesOptional integration — reads Search Console's Search Analytics API and writes the data series nothing else has.GA4 behaviour seriesOptional integration — reads the GA4 Data API and writes the behaviour series, the sibling to Search Console series.GTM audit and fixUnified Google Tag Manager audit-and-fix workflow.

See it work

A real run of WordPress REST inventory:

WordPress REST inventory · wordpress-rest-inventory
verdict: INFO
captured: <timestamp>
plugins: 3 (2 active)
themes: 1 (1 active)
users: 2
content: post 24 · page 12
routes: 6
application passwords: 0 (0 never used)

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

Two requests, one procedure, opposite risk profiles. Granting access badly is an inconvenience. Revoking it badly leaves someone who no longer works there holding the keys to a client’s analytics, ad spend and website — and the request is usually worded as though it were routine.

  1. List every system in scope before touching one. WordPress, Search Console, Analytics, Tag Manager, Google Ads, and the host. The request will name one or two; a leaver needs all of them, and the ones nobody thinks of are where access survives.
  2. Inventory who has access today. The WordPress client lists users and roles; the Search Console, Analytics and Tag Manager clients report the accounts attached to each property. Do this before the change, because it is also the only record you will have of what the state used to be.
  3. [manual] Make the change in each console. Grant at the lowest role that does the job — a marketing contractor almost never needs administrator on WordPress or edit on a Tag Manager container. For a revoke, work the list from step 1 and do not stop at the obvious two.
  4. Re-inventory and compare. Run the same reads again. The account should appear with the intended role, or be absent entirely. This is the step that catches a revoke that silently failed because the account was attached at the account level rather than the property level.
  5. [manual] For a leaver, rotate what cannot be revoked. Any shared credential they knew, any API key or application password issued to them. Revoking a named account does nothing about a password in a shared document, and that is the access that actually persists.
  6. Record what was changed, in the ticket and the activity log. Who, which systems, which roles, which date. Access changes are the ones asked about months later.

Least privilege, and why the inventory comes first

The default instinct on a grant request is to give administrator because it definitely works. It also means the next person to ask what changed on the site has one more candidate. Steps 2 and 4 exist because access drift is only visible as a diff — no console tells you that someone has had edit rights for two years and never used them.

What this does not cover

Granting or revoking anything. Every one of these clients is read-only by design, so this procedure inventories who has access and verifies afterwards that a change took effect — the change itself happens in each console by hand. It also cannot see access held outside these systems: a shared password, a personal Google account with a saved session, or a former employee still on a distribution list are all invisible here.

← All scenarios