A business can pay every website invoice and still be unable to prove who controls the domain, DNS, hosting, email, analytics, or WordPress account. The practical fix is a website ownership map: one record that names each system, the account that controls it, the responsible person, the recovery path, and the evidence that access still works.
This isn't busywork. Your domain and DNS can affect the website and email at the same time, while hosting, WordPress, analytics, and form delivery may belong to completely different accounts. When those pieces are treated as "the website," a provider change or staff departure can turn into a recovery project.
Separate the systems before you list the logins
Start with the systems, not a password spreadsheet. A useful ownership map normally includes:
- domain registrar;
- authoritative DNS provider;
- website host and control panel;
- WordPress administrator accounts;
- business email provider;
- analytics, tag management, and search accounts;
- form, payment, scheduling, and other critical integrations;
- backup location and recovery contact.
ICANN's registrant account guidance makes an important distinction: domain registration and DNS hosting are separate operations. That distinction matters because changing a nameserver or DNS record can interrupt the website, email, or both even when the web-hosting account itself is fine.
Record control, responsibility, and recovery
For each system, record four things.
Control: Which account can make consequential changes? Use the real account identifier or business-owned email address, not "the developer has it."
Responsibility: Who is expected to renew, monitor, or maintain it? The person doing the work may be different from the business owner who must retain control.
Recovery: Where do password resets and security notices go? A recovery address inside the same domain can become a trap if the domain or email service is the thing that failed.
Evidence: When was access last tested, and what did the test prove? A saved username is not proof that the credentials, multifactor method, or recovery path still work.
Do not put raw passwords into the ownership map. Store credentials in an appropriate password manager and use the map to document where they are held and who is authorized to use them.
Look for concentration risk
Convenience can hide a serious dependency. One former contractor may control the registrar, host, analytics, and backups. One inbox may receive every recovery message. One broad administrator login may be shared by several people.
I look for the failure that could lock the business out of several systems at once. Then I separate ownership from day-to-day access, add a second recovery route where appropriate, and make sure the business can reach support without relying on the system that is down.
Use the map during every handoff
A website handoff is complete when the business can identify its systems, reach the controlling accounts, understand what renews, and know who to call. Ask the outgoing provider to reconcile the map, remove obsolete access, transfer business-owned assets, and explain anything that cannot be transferred.
If you are planning a rebuild or provider change, the website project brief helps define the work. The ownership map protects the accounts and infrastructure the project depends on.
You do not need a perfect asset-management program to start. Make the first map, test the most consequential accounts, and schedule a review after any staff, vendor, hosting, or domain change. If the current ownership is unclear, an HQ Tech Consultation can help you identify the systems before anyone starts moving them.