Taking over a WordPress site from another agency

Day 1: every login, not just the admin one

The admin login is the one layer of five. Before anything else, go through the handover checklist and get the registrar, DNS, hosting and backup logins, or at least the names of who holds them. The old agency is most helpful in the first week and least helpful after the final invoice, so ask for everything now.

On the site itself: make your own administrator account, log in with it, then remove the old agency’s accounts and any shared one such as “admin”, “developer” or “support”. Change the passwords on every account that stays. Turn on two-factor login if a plugin provides it.

Day 1, afternoon: see what you actually have

• Versions. WordPress core, every plugin, the theme. Note what is out of date and by how much. A theme or plugin that has not been updated in two years may be abandoned, not just neglected.
• Paid plugins and their licences. Premium plugins update through a licence key, and the key is usually on the old agency’s account. When they cancel it, updates stop and so do security fixes. List them, and buy your own licences where it matters.
• What the site gives away. The WordPress version check shows whether the site publishes its versions in the page source and whether readme.html is still readable. Both tell an attacker where to aim.
• Users. Every account with a role above subscriber, and whether a public author page or the REST API lists their usernames.
• Backups. Find where they go and when they last ran. Then restore one to a staging copy. Until you have done that, you do not have backups; you have a setting.

Day 2: update, carefully

Take a backup you have tested. Update core, then the theme, then plugins a few at a time, checking the site between batches. A site that has not been updated in a year will usually break somewhere; it is far better to find that on a Tuesday afternoon with a backup in hand than after an attack. If the host offers a staging copy, do it there first.

Day 3: what the site depends on

The page source names most of it: analytics and tag manager containers, a chat widget, a form service, a newsletter signup, a payment provider, maps, fonts. Each is an account, each account has a holder, and some of them are on the old agency’s cards. For each one write down who holds the login, and move the ones that matter (analytics, payments, email sending) into accounts the client controls.

Then email: the domain’s SPF and DMARC records name every service that sends mail in its name. Run the SPF and DMARC checks. An SPF record that includes a service nobody uses any more is a sender you have not reviewed; a DMARC policy of p=none means faked mail in the client’s name is still delivered.

Day 4: the layers below

Check the domain with the domain expiry checker: the registrar, the date, whether it is locked. Check the certificate with the certificate checker, and the hosting with the who-hosts check. For each, the question is the same: whose account, whose card, where is the login. A WordPress site on a host nobody can log in to is not yours yet.

Day 5: write it down, and keep it true

You now know more about this site than anyone, and in six months you will have forgotten half of it. Record who holds each layer, with the date and your name on each answer, and write the first steps for an outage while you still remember which panel the host uses.

Stackbrace is built for exactly this week: it scans the site from outside and fills in what it can see, asks you for the rest, checks every version against known security holes every day, and tells you when something changes. The free check shows what it finds on any site without an account; the site record is where the rest goes.