A small business homepage is controlled by more than its visible editor. The domain registrar, DNS provider, hosting account, content management system, code repository, CDN, analytics property, search tools, forms, and plugins may each provide a separate path to change the site or view its data. An effective audit inventories those paths and assigns every permission to a named work need.
Build the control-plane inventory
Create one row for each system involved in the homepage. At minimum, check the domain registrar, DNS, web host, CMS, theme or page builder, source repository, deployment service, CDN or proxy, analytics, Search Console, form delivery, email marketing, consent tool, backup service, and payment or scheduling embeds. Record the primary owner, backup owner, every user, the sign-in method, the role, and the last time the role was confirmed.
Use named accounts instead of treating a shared password as a role. If a platform offers only one shared login, record that limitation and who stores the recovery information. Do not change recovery settings during an inventory unless the authorized owner is present and the replacement route has been verified.
Translate roles into actual capabilities
Role names vary, so record what the role can do. WordPress documents six predefined roles. An Administrator has all administration capabilities on a single site; an Editor can publish and manage posts, including posts created by others; an Author manages and publishes their own posts; a Contributor writes but cannot publish; and a Subscriber primarily manages a profile. The official WordPress roles and capabilities guide also lists the underlying capabilities, which is more useful than relying on the label alone.
Check high-impact capabilities separately: publishing pages, installing plugins, editing theme code, changing navigation, managing forms, exporting users, changing administrators, and altering site settings. A marketing writer may need page editing without plugin installation. A developer may need repository and deployment access without customer-form exports. Document the smallest practical combination instead of granting a broad role for convenience.
Review search and measurement accounts
Open Google Search Console's Users and Permissions page for the property. Google states that property owners can manage users and roles there, and its permission documentation distinguishes owners from full and restricted users. See Google's Users and permissions management guide and Search Console user permissions guide. Verify the current owners, delegated owners, and users against the people who still maintain or analyze the site.
Repeat the exercise for analytics, tag management, advertising pixels, business listings, and uptime monitoring. Pay special attention to accounts owned by a former agency or employee. If the business is not the verified owner, record an ownership-transfer task with evidence and an accountable person; do not create a duplicate property as a shortcut.
Inspect indirect change paths
List integrations that can publish or modify content: repository deploy keys, continuous-deployment tokens, CMS API keys, automation webhooks, page-builder licenses, form connectors, and plugins with external dashboards. For each one, write down who authorized it, what it can reach, where its secret is stored, and how to test it after a change.
Also inspect domain and DNS delegation. Record the registrar, nameservers, DNS administrators, renewal contact, and any proxy or CDN account. A beautifully restricted CMS does not cover a separate account that can redirect the domain.
Close the audit with verification
Make changes in layers. First confirm business-controlled ownership and recovery. Next remove departed users, reduce roles that exceed current duties, revoke unused integrations, and replace shared credentials with named accounts where the platform supports them. Avoid removing the only administrator or breaking a deployment token before a tested replacement exists.
After each group of changes, publish a harmless draft or staging update through the normal workflow, verify the homepage and form path, and confirm that the intended search and analytics users can still enter. Store the final register with the audit date, evidence link, unresolved items, owner, and next review date. The result should show not merely who appears on a user screen, but every known route that can affect the homepage.
Sources
- Roles and Capabilities — WordPress.org
- Managing owners, users, and permissions — Google
- Search Console Property Settings page — Google Search Console Help