Changing Agencies Without Losing Control: Who Actually Owns Your Website?
Domains, DNS, hosting, source code, and Search Console can work for years until an agency changes. This handover audit shows which accounts and ownership paths should be clear before the transition.
The website is online, invoices are paid, and the agency responds when something needs changing. That feels like control until the relationship ends.
Then somebody discovers that the domain registrar is known only to a former freelancer, DNS lives in a personal account, hosting is billed to the agency's card, or the source code sits in a repository nobody inside the business can administer. Google Search Console still contains old verified owners, and the consent platform was licensed through an external account.
The website is still live, but the business is operationally dependent.
A useful website handover is therefore not a ZIP archive plus a password list. It answers a more important question: Can the business continue to operate, pay for, secure, restore, and transfer the website without depending on the outgoing agency?
1. Ownership is bigger than a CMS login
Modern websites distribute control across many systems: registrar, DNS, hosting or cloud, CDN, source repository, CI/CD, CMS, database, backups, email delivery, analytics, tag management, consent platform, Search Console, monitoring, and third-party APIs.
A company can be an Administrator in the CMS and still lack practical technical control. If only the agency can change DNS, deploy a release, or renew the domain, a critical single point of failure remains.
The goal of a handover is not to give everyone maximum privileges. It is to build a clear ownership map: which system is critical, which organization controls the account, who may use it, and how access is recovered.
2. Start with the domain and registrar
ICANN directs registrants to their registrar for operational domain management such as renewal, contact information, and nameserver changes. The registrar should therefore never be an unknown part of the stack.
For each business-critical domain, you should be able to answer:
- Which registrar holds it?
- Which business-controlled account can access it?
- Which address handles account recovery?
- Who receives expiry and renewal notices?
- Is the payment method current?
- Is MFA enabled where supported?
- Who can trigger transfers or nameserver changes?
A warning sign is a domain that exists only inside one individual's personal account. That can work perfectly for years until the person becomes unavailable. The domain should be organizationally tied to the business, not to the current provider relationship.
3. Inventory DNS before touching it
DNS does more than point www.example.com to a website. Zones often contain records for email, SPF, DKIM, DMARC, domain verification, API subdomains, CDN targets, and Search Console ownership.
Rebuilding a zone during an agency change without understanding the existing records can therefore interrupt email or other connected services in addition to the website.
Before the handover, export or document the complete zone. For each important record, capture not only its value but also which service depends on it.
4. Hosting access is not the same as deployment capability
Many sites are no longer copied to one server by FTP. Releases may depend on GitHub Actions, GitLab CI, Vercel, Netlify, container registries, cloud providers, or custom pipelines.
Review two separate capabilities:
Operations: Can the business manage hosting, billing, logs, domains, and configuration?
Release: Can a new technical provider reproducibly build and deploy a new version from source?
A good dry run is simple: give a competent person the handover documentation, make a harmless text change in a safe environment, and follow the intended release path. If the outgoing developer's laptop is mandatory, operational knowledge is missing.
5. Source code and repository belong in the ownership review
The production server should not be the last surviving copy of the project. A handover should include the full repository, relevant history and branches, build and deployment configuration, documented dependencies, and infrastructure-as-code where applicable.
GitHub documents granular repository roles so access can match the work a person needs to perform. GitHub also recommends more than one organization owner so projects do not become inaccessible when the only owner is unavailable.
That gives a useful operating principle: critical technical assets should not depend on one personal account, while not everyone needs administrator access.
Also review deploy keys, service accounts, installed apps, and outside collaborators. Removing one agency user does not necessarily remove every technical access path.
6. Use named CMS accounts, not a shared admin password
WordPress officially defines roles and capabilities from Subscriber through Administrator and, for multisite, Super Admin. A mature setup uses that separation instead of one shared admin account used for years.
Named accounts make it possible to see who still has access and which permissions are actually needed. After an agency change, obsolete accounts can be removed without locking out internal users.
Licenses also deserve attention. Premium plugins, themes, and page builders may work today while being tied to an agency-owned account. "The license is active" is not the same as "the business can renew it next year".
7. Search Console: removing a user may not remove ownership
Google Search Console distinguishes between verified owners and delegated owners. Verified owners prove control through technical tokens such as DNS records, HTML files, or tags.
One handover detail matters in particular: Google's documentation explains that a removed verified owner may be able to verify ownership again while their old verification token remains in place.
Do not review only the visible user list. Also ask:
- Which verified owners exist?
- Which verification method does each use?
- Which obsolete tokens remain in DNS, HTML, or configuration?
- Is at least one verified owner directly controlled by the business?
The broader lesson is useful elsewhere too: removing account access and revoking proof of ownership are not always the same operation.
8. Include analytics, consent, and third parties
After hosting, the forgotten systems often appear: analytics properties, tag-manager containers, consent management, ad pixels, maps, chat, review widgets, transactional email, and external APIs.
For every service, document four things: owner, billing route, purpose, and technical integration. This reduces lock-in and makes future privacy, tracking, and maintenance reviews much easier because the team can explain which third party exists on the website and why.
9. Transfer secrets safely, not in an emailed password document
A handover needs access, but it does not need an unprotected collection of every credential. Move critical accounts to business-controlled addresses where possible, replace personal agency accounts with named accounts, and transfer secrets through an appropriate password or secret-management system.
CISA recommends MFA as an additional layer for online accounts. Registrar, hosting, repository, and central email accounts deserve priority. Recovery addresses and recovery codes should be reviewed as well.
Obsolete API keys, deploy keys, and service accounts should be rotated or revoked after the transition – but only after the new operating path has been proven to work.
10. Billing, backups, and restore are technical dependencies too
An old credit card can be an effective off switch. Domains, hosting, CDNs, premium plugins, transactional email, consent tools, or monitoring can depend on payment routes nobody inside the business knows about.
Document the contracting account, payment route, renewal model, and responsible person for each paid service. Then do the same for recovery: where are backups stored, which account controls them, and how is a restore started?
If only the outgoing agency knows how to restore a backup, the backup may exist technically while recovery remains operationally dependent.
Twelve red flags for a fragile handover
- The domain lives in a provider's personal account.
- Nobody inside the business knows the registrar.
- A critical account uses an agency-controlled recovery address.
- One person is the only owner of the source-code organization or repository.
- There is no reproducible deployment process.
- Production secrets exist only on a developer's device.
- CMS access depends on one shared administrator login.
- Former staff or providers still have administrative access.
- Search Console contains unknown or obsolete verified owners.
- Licenses can only be renewed through the outgoing agency account.
- Backups exist, but nobody outside the agency knows the restore path.
- There is no current inventory of technically connected services.
None of these items automatically proves poor agency work. Many dependencies grow organically over years. They become dangerous when they remain unknown.
The better handover test: a controlled dry run
Before the relationship ends, the business and incoming technical contact should practically verify the path: open the registrar, export DNS, access hosting and billing, clone the repository, build the project from documentation, perform a harmless test deployment, review CMS roles, inspect Search Console owners and tokens, verify analytics and consent access, and walk through backup and restore documentation.
Only after that path works should obsolete external access be reduced. This exposes missing information while the outgoing provider can still answer questions.
What Website-Pflichtencheck would inspect during a handover
A website handover review can examine registrar and recovery paths, DNS and nameservers, hosting and CDN ownership, repository roles, build and deployment documentation, CMS accounts, Search Console owners and leftover verification tokens, analytics and consent access, backup and restore responsibility, external API accounts, licenses, billing dependencies, and obsolete provider access.
The useful output is not a password list but a prioritized ownership map: What is critical, who controls it, who can recover it, and what happens if today's contact is unavailable tomorrow?
A good agency does not create value by making itself the only party capable of operating the website. It creates value by leaving behind a system that is understandable, maintainable, and transferable.
If your website only works while the same person remains reachable, you may own a website, but you do not yet have resilient website operations.