The worst time to find out who owns your domain is the week your website goes down.
The second worst time is when you’re trying to fire an agency, change hosting, rebuild the site, recover analytics, fix email delivery, or prove ownership in Google Search Console.
Most small business website problems are not caused by one giant mistake. They’re caused by a messy trail of accounts nobody documented. The old marketing person used a personal Gmail. The developer set up hosting under their card. The domain renewal goes to an inbox no one checks. The Facebook pixel belongs to a freelancer from three years ago.
This is the website access inventory I wish every business owner had before there was a problem.
Use it as a working template. Copy it into a spreadsheet, password manager note, or internal wiki. The goal is simple: know what exists, who controls it, how access is granted, and what happens if that person leaves.
Why a Website Access Inventory Matters
Access is not admin busywork. Access is business continuity.
Verizon’s 2025 DBIR research found compromised credentials were an initial access vector in 22% of breaches. The same research found that, in the median case, only 49% of a user’s saved passwords across services were distinct after an infostealer infection. That is a polite way of saying reused passwords turn one account problem into several.
Domain ownership has its own risk. ICANN says domain registrants must keep accurate and reliable contact information with their registrar, and failure to verify or update that information can lead to suspension or cancellation. If your domain contact email belongs to an ex-employee, you may not see the warning until the site is already offline.
Search access matters too. Google says a verified Search Console owner has the highest degree of permissions, including access to sensitive search information and actions that can affect a site’s presence in Google Search. If the only verified owner leaves, Google says you should verify ownership to maintain or regain access.
And when you move hosting, Google recommends testing the new infrastructure, checking Googlebot access, lowering DNS TTL in advance, and making sure Search Console verification continues to work. You cannot do that cleanly if nobody knows where DNS lives.
The Rule: Own the Account, Delegate the Access
Your business should own the root accounts. Vendors should get delegated access.
That means the domain registrar, hosting account, Google Business Profile, Search Console, Analytics, ad accounts, CRM, email platform, and payment tools should be tied to business-controlled identities, not a vendor’s private account.
This does not mean every owner should personally manage DNS records or plugin updates. It means the business can recover, revoke, transfer, and audit access without begging a third party.
Use these fields for each item in your inventory: account or asset name, URL or login location, owner email, admin users, vendor users, MFA status, backup recovery method, renewal date, billing card owner, last reviewed date, and notes about risks or dependencies.
Keep passwords in a real password manager, not in the spreadsheet. The inventory tells you what exists and who owns it. The password manager stores the secret.
1. Domain and DNS Access
Your domain is the front door. If you lose it, everything else gets harder.
Document these items:
| # | Access item | What to record |
|---|---|---|
| 1 | Domain registrar login | Provider, login URL, account owner, and backup admin |
| 2 | Domain registrant contact email | The mailbox that receives official domain notices |
| 3 | Domain renewal date | Renewal date, term length, and auto-renew status |
| 4 | Payment method owner | Card or billing owner, without storing card numbers |
| 5 | Domain lock status | Whether transfer lock is enabled |
| 6 | DNS hosting provider | Where nameservers and records are managed |
| 7 | Nameserver records | Current nameservers and why they point there |
| 8 | Core DNS records | A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC, and verification records |
| 9 | Recovery route | Who can regain registrar access if the primary admin is unavailable |
| 10 | Last review date | Date, reviewer, and open risks |
The key detail is not just where the domain is registered. It is who receives registrar warnings. ICANN’s RDRP FAQ says registrars send annual reminders to review and update domain contact information. If those reminders go to a dead inbox, your protection system is broken.
For DNS, write down what each important record does. A TXT record might verify Google Search Console, Microsoft 365, HubSpot, Mailchimp, Stripe, or a security tool. Delete the wrong one and something breaks quietly.
2. Hosting, CDN, and Deployment Access
Hosting access controls the live site. It also controls backups, logs, SSL certificates, redirects, staging environments, and sometimes email.
Document these items:
| # | Access item | What to record |
|---|---|---|
| 11 | Hosting provider login | Provider, project name, admin owner, and billing owner |
| 12 | Server or project name | Production environment and any staging environment |
| 13 | CDN account | Cloudflare, Fastly, host-managed CDN, or other edge provider |
| 14 | SSL certificate source | Where certificates renew and who gets expiration alerts |
| 15 | Backup location | Backup schedule, storage location, and restore instructions |
| 16 | Deployment platform | GitHub Actions, Netlify, Vercel, WP Engine, cPanel, or similar |
| 17 | Code repository | Repo URL, owner organization, deploy branch, and admin users |
| 18 | Secret storage | Where environment variables and API keys live |
| 19 | Rollback process | Who can roll back and how long it takes |
| 20 | Last restore test | Date of the most recent backup restore test |
This is where many website handoffs fail. The business has WordPress access, but not hosting access. Or the agency has GitHub, but the owner has Cloudflare. Or backups exist, but no one has tested a restore.
Google’s hosting migration guidance recommends copying and testing the site before a move, reviewing pages, images, forms, and downloads, and monitoring traffic on old and new servers. That checklist assumes you can get into both environments.
3. CMS and Website Admin Access
The CMS is where day-to-day website damage usually happens.
Document these items:
| # | Access item | What to record |
|---|---|---|
| 21 | CMS admin URL | Login URL and platform name |
| 22 | Primary admin account | Business-controlled admin account |
| 23 | Backup admin account | Second owner-level account for recovery |
| 24 | Editor and author accounts | Named users and current role assignments |
| 25 | Plugin or extension licenses | License owner, renewal date, and vendor support access |
| 26 | Theme or builder account | Theme license, page builder account, and renewal owner |
| 27 | Form plugin account | Where forms are built, stored, and routed |
| 28 | Security plugin account | Alerts, firewall rules, scans, and lockout controls |
| 29 | Ecommerce, membership, or booking access | Store, calendar, subscription, or member-management admins |
| 30 | User role policy | Which roles each team or vendor should receive |
Do not let everyone be an administrator. Give people the lowest role that lets them do their job.
For WordPress, that usually means owners and trusted technical staff are admins, content people are editors, writers are authors, and outside specialists get temporary access. For Shopify, Webflow, Squarespace, Wix, or another hosted platform, use their role system instead of sharing one login.
Also record which plugins or apps are business-critical. A form plugin, redirect plugin, ecommerce integration, or booking calendar can be just as important as the CMS itself.
4. Analytics, Search, and Tagging Access
Analytics access is easy to ignore until a campaign fails and no one can explain what happened.
Document these items:
| # | Access item | What to record |
|---|---|---|
| 31 | Google Analytics property | Property ID, account owner, admins, and key events |
| 32 | Google Tag Manager container | Container ID, publish rights, and connected tags |
| 33 | Google Search Console properties | Domain and URL-prefix properties with verified owners |
| 34 | Bing Webmaster Tools | Verified site, admins, and sitemap submissions |
| 35 | Looker Studio dashboards | Report owners, data sources, and sharing rules |
| 36 | Call tracking account | Numbers, tracking sources, and routing rules |
| 37 | Heatmap or session recording tool | Tool owner, privacy settings, and retention period |
| 38 | Consent management platform | Cookie banner owner and consent mode settings |
| 39 | UTM naming document | Source of truth for campaign naming |
| 40 | Conversion event definitions | What counts as a lead, sale, signup, or qualified action |
Google recommends adding more than one Search Console verification method in case one method fails. That is practical advice for business owners, not just SEOs. If your only verification method is a tag in a theme file and the theme changes, access can break.
Search Console should have at least two verified owners tied to business-controlled accounts. Google Analytics and Tag Manager should be owned by the business too. Agencies and contractors can be admins or editors, but they should not be the only owners.
5. Marketing, Sales, and Reputation Access
Your website is connected to the tools that turn traffic into revenue.
Document these items:
| # | Access item | What to record |
|---|---|---|
| 41 | Google Business Profile | Primary owner, managers, locations, and recovery email |
| 42 | Google Ads | Account ID, billing owner, conversions, and linked properties |
| 43 | Meta Business Manager | Business ID, page admins, pixel owner, and ad account access |
| 44 | LinkedIn Campaign Manager | Ad account, page admins, and billing owner |
| 45 | Email marketing platform | List owner, templates, signup forms, automations, and sending domain |
| 46 | CRM or pipeline tool | Lead routing, form integrations, pipeline owner, and admin users |
| 47 | Review platforms and directory listings | Claimed profiles, owners, and notification email addresses |
This category gets messy because marketing tools are often created in a hurry. A freelancer sets up a pixel. A salesperson starts a CRM trial. Someone connects Zapier to a form. Six months later, the tool is important, but ownership is unclear.
Write down which website forms feed which systems. If the quote request form goes to HubSpot, Slack, a Google Sheet, and email, document every stop. That makes troubleshooting faster when leads suddenly stop showing up.
Security Rules for the Inventory
A website access inventory is only useful if it does not become a security problem itself.
Follow these rules:
- Store passwords, recovery codes, API keys, and private keys in a password manager or secrets manager, not in the inventory document.
- Require MFA on domain, hosting, CMS, email, analytics, ad, CRM, and payment accounts.
- Use business email addresses for ownership, not personal inboxes.
- Give vendors named user accounts instead of shared logins.
- Remove access when a vendor, employee, or contractor leaves.
- Review the inventory every quarter and before any redesign, migration, ownership change, or agency switch.
CISA recommends multifactor authentication for small and medium businesses and says businesses should aim to use phishing-resistant MFA. If a tool offers hardware keys, passkeys, authenticator apps, or admin-level MFA enforcement, use them for your highest-risk accounts first.
The highest-risk accounts are usually email, domain registrar, DNS, hosting, CMS admin, payment processing, Google Workspace or Microsoft 365, and any tool that can publish code or change tracking scripts.
Red Flags to Find During Your Audit
If you only have time for a 30-minute check, look for these problems first:
- The domain registrar uses an old employee email.
- The website host is billed to a vendor card.
- The business has no admin access to DNS.
- Search Console has one verified owner, and that owner is not the business.
- Google Analytics or Tag Manager sits inside an agency-owned account.
- WordPress has several old administrator accounts.
- Forms send leads to personal inboxes.
- Backups exist, but no one knows how to restore them.
- Plugin licenses belong to a vendor with no transfer plan.
- MFA is missing on domain, hosting, CMS, email, or ad accounts.
Any one of these is fixable. The danger is letting them stack up until a normal website change becomes an emergency.
The 60-Minute Access Inventory Process
You do not need a giant consulting project to start. Set a timer and do this:
First 15 minutes: find the domain registrar, DNS provider, hosting provider, CMS admin URL, and business email admin console. These are the spine of the website.
Next 15 minutes: list the connected measurement tools, including Analytics, Search Console, Tag Manager, call tracking, heatmaps, and dashboards.
Next 15 minutes: list the revenue tools, including forms, CRM, email marketing, ad accounts, review platforms, ecommerce, booking, payment, and automation tools.
Final 15 minutes: mark each item as green, yellow, or red. Green means business-owned with MFA and backup admin access. Yellow means usable but messy. Red means unknown, vendor-owned, personal-email-owned, or missing MFA.
Then fix the red items one by one.
What to Ask Your Web Vendor
A good web partner will not be offended by access questions. They will be relieved you care.
Ask these before starting a redesign, migration, or support agreement:
- Which accounts should our business own directly?
- Which accounts will you need access to?
- Will your team use named users or shared logins?
- How will access be removed when the project ends?
- Where are backups stored, and when was the last restore test?
- Who controls DNS and deployment?
- What happens if our primary contact is unavailable?
- Will we receive documentation at handoff?
If the answer is, “Don’t worry, we handle everything,” slow down. Convenience is nice until it turns into dependency.
FAQ: Website Access Inventory
What is a website access inventory?
A website access inventory is a list of the accounts, assets, owners, admins, vendors, renewal dates, and recovery methods connected to your website. It should cover domain, DNS, hosting, CMS, analytics, marketing, sales, security, and payment tools.
Should passwords go in the inventory?
No. Put passwords, recovery codes, API keys, and private keys in a password manager or secrets manager. The inventory should tell you what exists, who owns it, and where secure access is stored.
Who should own the domain account?
The business should own the domain account through a business-controlled email address. ICANN says registrants must provide accurate contact information and update it promptly when it changes.
How often should we review website access?
Review it quarterly, before major site changes, after employee departures, before switching vendors, and before domain or hosting renewals. Also review it after any security incident.
Can Your Web Team help with this?
Yes. If you want someone to map your website access, flag ownership risks, and turn the mess into a usable handoff document, get started here.
