WordPress Site Takeover — Checklist for Taking Over Care [2026]

Taking over a WordPress site under care is the process of transferring responsibility for the site from a previous vendor (or from "nobody's hands") to a new caretaker — with an inventory, an audit, clean-up of access and a smooth transition to ongoing care. A well-run takeover does not start with an invoice, but with an audit; it does not end with passwords, but with full control over the site: domain, code, backups and documentation.

Key takeaway: A site takeover has five stages: access inventory → technical audit → regaining control (domain, hosting, code) → clean-up (plugins, backups, staging, monitoring) → start of ongoing care. The key rule: access to the domain and hosting must belong to the site owner, not the vendor. If the previous vendor blocks access, claiming access to your own property (domain, server, code) is a legal matter — not a negotiation. A takeover with an audit takes 1–2 weeks.

When to think about taking over a site

Changing a care vendor is a normal part of a site's life — vendors disappear, close down, raise prices or simply stop being available. Signs that it is time for a takeover:

• The previous vendor does not respond — tickets without a reaction, no reports, "I'll get back to you" without a date.
• You do not have access — the domain registered "to the vendor", hosting on their account, no access to files.
• The site is neglected — outdated plugins, no backups, PHP past EOL, no updates for months.
• You are ending collaboration with an agency — you are taking over the site after a build or maintenance contract ends.
• The site was "someone's after-hours project" — it works, but nobody knows how it is built and what is inside.

A separate case is taking over a site after failed maintenance: when the site has already been "cleaned" after malware, after an outage without a backup, or after a sudden ranking drop in Google. Then the takeover starts from an emergency state, and clean-up is more urgent.

How the takeover runs step by step

Five stages that lead from "site on someone else's account" to "site under full control and care".

• Stage 1 — Access inventory — collecting all the keys to the site: domain, hosting, WordPress panel, database, DNS, email accounts, Search Console, Analytics. This is the stage that most often drags on — and the most important.

• Stage 2 — Technical audit — a review of the site's condition: security, performance, plugins, backups, infrastructure (WordPress site audit). Output: a list of problems with priorities and repair estimates.

• Stage 3 — Regaining control — moving the domain to the client's account, hosting to the right account, establishing code ownership (a Git repository or at least a complete file copy).

• Stage 4 — Clean-up — removing unnecessary plugins and accounts, configuring backups with tests, starting monitoring, setting up staging.

• Stage 5 — Start of ongoing care — an agreed update cycle, ticket channel, SLA, reporting. From this moment the site lives in care mode (WordPress website care).

• A realistic takeover time: 1–2 weeks for a typical company site, longer when access has to be recovered by force or when the technical condition requires repair first.

Access checklist — what must move to the client

This list is the heart of the takeover. Every item should belong to the site owner — not the vendor.

• Domain — a registrar account with access to the DNS panel; the domain registered to the client's details.
• Hosting / server — an account with the hosting provider, with access to the management panel, files and databases.
• WordPress panel — an administrator account; passwords of other accounts reset at handover.
• File access — FTP/SFTP or SSH, preferably with your own keys.
• Database — database credentials and the ability to export.
• Email accounts — mailboxes on the domain and access to mail configuration (MX, SPF, DKIM).
• Google Search Console — access (preferably ownership) to the site profile.
• Google Analytics / GA4 — administrative access to the property.
• Source code — a Git repository if one exists; if not, a full copy of files from the server.
• Third-party service accounts — payments, couriers, newsletter, CDN, WAF, premium plugin licences.

After the handover, change all passwords and enable 2FA. The handover is also the moment to check whether any "third party" still has access — a list of panel users, FTP accounts, API keys.

When the previous vendor blocks access

This is a more common scenario than one would like to admit. Fortunately, in most cases the law and procedures stand on the site owner's side.

• Establish ownership — is the domain registered to the company's details? is hosting paid with the company card? If so, you have ownership documents and can act directly with the providers.
• Contact the domain registrar — for a domain registered to the client's details, regaining control through identity verification is a standard procedure.
• Contact the hosting provider — if the hosting account belongs to the client (payments from their card), the provider can restore access to the account after verification.
• Document contact attempts — a written demand to release access with a deadline; this is the basis for any claims.
• Last resort: rebuild — if access is unreachable and the site is running, it can be rebuilt from public copies (scraping does not return the database and functions) — but this is an emergency operation and expensive, requiring rebuilding content and configuration.

The conclusion for the future: a clause on ownership of the domain, code and access should be in every contract from day one.

Inventory and audit of the site being taken over

After collecting access, the site goes through an audit. The scope is broader than a regular review — the point is to get to know the site, not just assess it.

• Site map — structure, number of pages, templates, key user paths.
• Plugins and theme — what is installed, what is active, what is abandoned; versions and premium licences.
• Code modifications — child theme, custom plugins, core changes (a red flag — they will be overwritten on update).
• Security status — malware scan, accounts, permissions, server configuration (WordPress malware removal).
• Backups — whether they exist, where, how often and whether tested.
• Performance — Core Web Vitals, front-end-heavy plugins, database condition.
• Technical SEO — indexation, canonicals, redirects, sitemap, structured data.
• Integrations — payments, couriers, newsletter, CRM, feeds — what is connected and on which accounts.

The inventory output is a "takeover state" document: what the site has, what threatens it, what needs repair and in what order. This document protects both sides — the new caretaker is not responsible for problems they did not see, and the client knows what they are paying for.

Clean-up after the takeover

The first clean-up looks similar in every takeover. It is an investment in peace of mind for the coming months.

• Updates with a difference review — updating everything one by one, through staging, with tests (WordPress staging).
• Plugin pruning — removing unused ones; practice shows that out of 30–40 plugins, 10–15 are actually needed.
• Accounts and permissions — removing inactive accounts, least-privilege principle, 2FA for administrators.
• Backups from scratch — a new, tested backup system: cycle, retention, off-server storage, restore tests.
• Monitoring — availability, SSL, domain, forms, security; alerts to the caretaker (website monitoring).
• Documentation — what is on the site, where the access is, how deployment works; a document that survives a vendor change.
• Code versioning — a Git repository for custom code and the child theme; file copies are not enough to deploy changes safely.

The order is not accidental: protection first (backups, accounts), then clean-up (plugins, updates), finally improvements (staging, monitoring). The reverse order is cleaning without a safety net.

The first month of care

The first month after the takeover has its own rhythm. The agreed scope of work looks like this.

• Week 1 — finishing the clean-up, configuring monitoring and backups, the first full update cycle through staging.
• Week 2 — observation: logs, performance, forms and integrations after the changes; configuration corrections.
• Week 3 — work from the audit list with "important" priority: performance fixes, database clean-up, small content fixes.
• Week 4 — the first monthly report: what was done, what was found, what is planned for the next month.

After the first month the site enters normal care mode — an update cycle, monitoring, reporting, support on tickets (WordPress technical support). A good closing of the takeover is a short summary for the client: starting state, work performed, current state, plan for the quarter.

Contract and takeover documentation

The takeover should be written down — even when the new caretaker is the same person who built the site. The care contract, in the part concerning the takeover, specifies:

• Takeover scope — what is included in the process (audit, clean-up, migrations) and what is a separate project (e.g. rebuilding a site without access).
• Ownership and access — confirmation that the domain, code and accounts belong to the client; the vendor's obligation to hand over documentation.
• Responsibility for the starting state — the audit report as an annex; separating "inherited" problems from new ones.
• SLA and care scope — the standard package clauses: response times, backups, reporting.

A model set of clauses — including access and termination clauses — is collected in the article on WordPress website care.

Frequently asked questions

How long does a site takeover take?

A typical company site takeover takes 1–2 weeks: access inventory (1–3 days, longer if access must be recovered), audit (2–5 days), clean-up and configuration (3–5 days). Sites in poor technical condition require repair first, which extends the process by another week or two.

What if I do not have access to the domain?

If the domain is registered to the company's details, you can recover it through the registrar after identity verification — a standard procedure. It is worse when the domain is registered to the vendor's details: then their action or a legal route is needed. That is why the domain should always be registered to the site owner.

Does the new vendor need access to Google Analytics and Search Console?

They should — without Search Console the SEO audit and visibility monitoring are only half done, and without Analytics you cannot measure results. Access is granted at the permission level (the account does not have to be handed over) — in GSC as a user, in GA4 as an administrator or editor. The client remains the profile owner.

How much does a site takeover cost?

The takeover itself with an audit costs 500–2,500 PLN net (depending on the site's condition and the number of integrations), and is often included in the first month of care under a longer contract. Repair work resulting from the audit is priced separately — from a few hundred to several thousand PLN for neglected sites.

Will the takeover cost me my current Google positions?

A properly conducted takeover does not affect positions — the domain, URLs and content remain unchanged. Risk appears with a "rebuild during takeover": URL structure changes without redirects or a hosting migration without tests. The safe order is takeover → stabilisation → only then changes.

What if the previous vendor refuses to hand over access?

Document everything in writing: a demand to release access with a deadline, the correspondence, proof of ownership (invoices, registrar details). Where the domain and hosting are paid by the client, providers can restore access after verification. The last resort is the legal route — a claim for release of property. An ownership clause in the contract eliminates this problem for the future.

Sources and tools

• WordPress.org — support
• WordPress — hardening and security
• Google Search Central — site maintenance
• ICANN — domain owner rights
• OWASP — web application security

👉 Taking over a site and need order? See WordPress development & care — audit, clean-up and ongoing care with an SLA. Write via the contact form or to kontakt@informatix.com.pl.

📖 See also: WordPress website care, WordPress site audit and WordPress technical support.