Take over WordPress access after a collaborator leaves

Authorize access takeover after a departure

The fictional association Les Jardins du Canal is preparing for the departure of the person managing its site. Two members can still open WordPress administration, but renewal notices no longer reach a monitored address. Camille’s mandate is to inventory the association’s access, have providers confirm account holders and prepare authorized credential rotation.

For one site, the WordPress administrator, hosting-contract holder and domain holder may be three different people. For each service, identify who can authorize an action, who can execute it and which document links the service to the organization. Note “to confirm” when information rests on a memory or displayed name.

Define the mandate before opening accounts. Specify the site, covered services, authorized decision-makers, departure date and private channel for keeping the file. Separate permission to view from permission to transfer, revoke or modify. Examples use fictional identities, addresses and references. Rehearse on paper or in an isolated environment with fictional accounts.

Separate services and their holders in a private record

Prepare a tracking document restricted to authorized people. Create one row per service: WordPress administration, hosting, domain registration, email, DNS and any subscriptions necessary to the site. For each row, record the provider, listed holder, recovery contact and person currently able to log in.

Keep contract or invoice references identifying the correct file. Do not put passwords, backup codes or application keys in this record. Indicate only their location in the authorized secrets manager and who can access them.

Distinguish information confirmed in the service account from an oral recollection. An old invoice paid by an employee may be useful evidence without proving that employee still manages the current contract. Add each verification date and outstanding points.

The expected result is a record of responsibilities by service. You should be able to identify which provider to contact, on behalf of which organization and for which service. If domain and hosting belong to separate files, keep that separation until clarified.

Complete the fictional association’s record

This record represents the fictional file before any credential rotation. The domain jardins.example and reference FAC-DEMO-042 are only for rehearsal. One row may be green while another provider still examines its own request.

Add the date, service, authorized scope, approver’s name and case status. Use four simple states: “confirmed”, “missing document”, “awaiting support” and “verified after handover”. Secrets remain in the authorized vault. Supporting documents remain in the designated private space and are shared only with the relevant provider through its official channel.

• WordPress administration. The association’s administrator confirms Camille’s mandate and identifies the site. Camille prepares an individual account on the copy.
• Plan and billing. FAC-DEMO-042 matches the file. Camille asks the provider to confirm the holder.
• Domain and DNS. The renewal deadline is known. Camille asks support to verify the holder while preserving current settings.
• Newsletter sending. The integration manager found the job and key identifier in the private inventory. They prepare its replacement in the sandbox.

Read remaining WordPress access without changing it

If an authorized session works, open Users, then All Users. Record usernames, roles and people recognized by the administrator. View your profile to verify the email associated with your own account. A public name such as “Équipe” does not necessarily identify one person.

Do not immediately rename the shared account to assign it to the new collaborator. This could make history even less understandable without changing connections used elsewhere. Nor should you delete old accounts to simplify the list: their content and relationships must be examined separately.

In a multisite network, ask the super administrator to confirm scope. A subsite administrator and network administrator do not have the same powers. A site’s visible list does not necessarily represent the entire network organization.

On WordPress.com, also compare purchases and their holder in the relevant account. Administrator status does not give control of purchases belonging to another identity. Record a missing invoice or transfer button in your account as an access limitation without concluding that the service no longer has an owner.

Verify domain and hosting with available documents

Find domain invoices and renewal notices in authorized business archives. Note the registrar, account reference and expiry date. Do the same for hosting and email. One provider may group several services, but holders and deadlines still need verification.

Looking up domain registration data may help identify the registrar and DNS servers. This data does not always provide a usable public identity. A privacy service or hidden data does not prove the domain is abandoned or belongs to the person visible on the site.

In the provider panel, view account, contact, contract or billing sections without saving changes. Compare information with the takeover mandate. Separately verify whether the technical contact is authorized to transfer the contract.

If nobody has this access, start with the official procedure of the provider identified on the invoice. Prepare references actually held and open the request on behalf of the organization. The useful result is an identified service file with an explicitly confirmed recovery or handover route.

Arrange handover with an available holder

When the account holder still responds, request an organized handover of relevant services. Specify the site, subscriptions, domains and recipient. Simply sharing a password often leaves recovery and billing in the former collaborator’s name.

On self-hosted WordPress, hosting-contract and domain transfer follow their providers’ procedures. Creating a separate WordPress user may meet maintenance needs, but transfers neither contract. Have necessary tasks and permissions separately approved by the authorized administrator.

On WordPress.com, the current holder must check the items they own before a site transfer. The site owner, plan owner and domain owner may differ. Do not undertake a global transfer merely to provide writing access.

Prepare a receipt check: the recipient must find the correct site, expected services and intended recovery contacts. Keep confirmations and old billing references. Until receipt is verified, avoid closing the only access still allowing service management or responses to validation requests.

Understand and check an authorized WordPress.com transfer

For an approved handover, the current holder follows the process below. In an exercise, read the steps and simulate decisions with the fictional file. In the WordPress.com hosting dashboard, they select the site, open Settings, then Danger zone and Transfer. This option does not appear for an ordinary administrator who is not the site owner.

The holder enters the recipient’s identity and continues to the summary. They must check the stated scope: site, purchases and domains they own. Before final confirmation, they can still stop if the recipient or services do not match the agreed handover.

After initiation, authorization requested by email from the holder forms part of the process. The recipient then receives the expected confirmations. Check these messages in the usual mailboxes and inspect the received site before declaring transfer complete.

The previous owner may retain an administrator role, and old invoices remain linked to their history. After validation, also check contact details for the transferred domain. An error discovered after finalization requires another authorized procedure with the relevant provider.

Direct recovery of your own account

If the inventory confirms the blockage concerns only your own account, follow the corresponding provider’s official recovery procedure. For self-hosted WordPress, the forgotten WordPress password guide details the case of a holder who lost access. On WordPress.com, start from the official recovery page. For a former collaborator’s personal account, proceed through support’s site- or domain-takeover process.

Ask support to recover a service whose holder has left

1. In the private file, have the authorized person reconcile the site, contract and documents. Check the reachable contact address and domain deadline. Classify evidence by what it demonstrates. An invoice may link payment to the organization. The mandate establishes who represents it for the request. A domain email address may supplement the file.
2. Open the official page of the provider identified in the contract. For a WordPress.com site or domain registered by an unreachable former holder, follow the Account Recovery link from the dedicated page. Specify the service, your relationship to the organization, contact address and known deadline. Wait for the confirmation email and follow instructions for supplying requested documents. For self-hosted service, follow the host’s or registrar’s procedure.
3. Record the case number and next action. Until the provider confirms takeover and the affected service, the row remains pending. If support requests another document or refuses, return to the case owner. Deadlines continue during review. Ask the provider to specify authorized options if renewal is approaching.
4. After approval, verify that the decision covers the requested site, plan or domain and that the named recipient falls within approved scope. Site approval does not close plan or domain cases. Separately note what remains open.

Prepare and validate credential rotation

On a WordPress copy, have a fictional Contributor account save its own draft. Check that it cannot publish and the draft remains available. Separately check a fictional administrator’s access to settings. This exercise concerns editorial permissions; site or domain takeover remains a provider procedure.

1. Write the rotation order with the authorized administrator. Distinguish human accounts, their sessions, panel access, application passwords, tokens and automation keys. Assign each row an owner, dependency, verification and stop criterion. A writing account receives permissions necessary for its work.
2. Prepare the replacement account and recovery methods within approved scope. Rehearse receipt with two fictional accounts on the copy in separate profiles. The writing account must save its fictional draft. Its available actions must remain limited to the expected role. For a fictional integration, rehearse connection to a local service or mock, then verify the expected result.
3. After recipient validation, the administrator performs handover and revocation operations in the approved order on relevant services only. For an integration, enter the new reference in the authorized vault and consuming service. Confirm the switch before removing old authorization. On self-hosted WordPress, application passwords are managed from the profile when available. Track browser-session removal and application-password revocation separately. Preserve content and document authorship before removing an old account.
4. If receipt fails, suspend remaining revocations and use authorized backup access to correct permissions or service assignment. If authorization was already revoked, the authorized person prepares new targeted access through the provider’s procedure. If the inventory reveals an administrator of unknown origin, refer the case to the security lead.

Check continuity and recovery information

Check takeover service by service. The responsible person must find the correct site, intended domains and corresponding deadlines. Verify receipt of confirmations in authorized mailboxes and access to the necessary panel through the new route. Successful WordPress login does not yet validate hosting billing.

Record where recovery methods are stored, who may use them and who substitutes for the responsible person when absent. For two-factor authentication, keep backup codes in a protected location. Do not test the plan by closing every session or revoking the only working method.

On WordPress.com, separately check purchases actually received and transferred-domain contact details. In multisite, have remaining super-administrator responsibilities confirmed. For a domain registered elsewhere, WordPress handover does not replace checking with the registrar.

Keep handover confirmations and a next-review date. If a service remains under an inaccessible account, leave that point open in the record. Do not present the case as closed merely because the team can write again: continuity also depends on renewals and access that allows site recovery.

Close each row with a verifiable result

Replay the fictional case while varying one result. Suppose fictional support confirms site handover but requests another document for the domain. Camille records site receipt as confirmed and keeps the domain pending. The newsletter manager then finds that the new fictional key works in the mock. They validate that row independently of the domain. Domain rotation remains suspended until the provider decides.

At closure, the record distinguishes receipt of each service, recovery-method checks, removed access and open cases. Note the backup account’s location and next review date. A second authorized administrator reviews rows affecting renewal, email and automation. If uncertainty remains about the holder, the case stays open with a named action and contact.

Validate handover with a reference integration

For every automated access affected by the holder’s departure, record the service using it, its future owner and a check operation without public consequences. A WordPress application password belongs to a user and serves APIs; it is not the dashboard login password. Successful human reconnection therefore does not validate an integration.

The new owner configures the replacement in the authorized service, performs the check and then revokes the identified old access according to the handover plan. Keep result records, never secrets in the minutes. If the check fails, correct service configuration before revoking another integration. Do not regard old access as revoked merely because its name was removed from a document: verify its status in the issuing account.