Business Website Ownership Checklist: What Should Your Business Control?
Use this business website ownership checklist to secure your domain, hosting, code, Google accounts, content, backups, integrations, and vendor exit plan.
A business website ownership checklist should cover more than who designed the site or whose name appears on the invoice. Your business needs practical control over the domain, hosting, website platform or source code, analytics, Google accounts, business email, content, images, backups, integrations, billing, and recovery methods. Legal ownership and administrative access are not always the same: you might own certain content under a contract but still be unable to log in, move the site, or renew a critical service. Use this checklist before hiring a website provider, during a vendor change, and at least once a year to identify missing access, unclear contract terms, and assets tied to a former employee or vendor.
Key takeaways
Register the domain in an account controlled by the business, with current contact details, recovery methods, renewal information, and payment settings.
Make sure the business has administrator-level access to hosting, the website platform or code repository, analytics, Google Business Profile, business email, and lead-generation tools.
Do not assume that paying for a website automatically transfers copyright in contractor-created code, copy, photos, or graphics; check the signed agreement.
Document each account's owner, administrator, vendor access, renewal date, billing method, recovery method, and offboarding steps.
Require a written vendor exit plan covering exports, backups, credentials, code or platform transfer, DNS changes, third-party licenses, final fees, and a transition timeline.
The difference between legal ownership and practical control
Website ownership has two separate parts.
Legal ownership concerns rights created by contracts, copyright law, licenses, and payment agreements. It determines whether your business owns or is licensed to use items such as custom code, written content, photographs, graphics, and design assets.
Practical control means the business can log in, manage users, update billing, renew services, download data, create backups, and move to another provider. A contract may say you own the content, but that does not help during an outage or vendor dispute if only the vendor can access the account.
The reverse can also happen: having an administrator login does not necessarily mean the business owns every underlying asset. Stock photographs, fonts, plugins, templates, platform components, and third-party code may remain subject to separate licenses.
Under U.S. Copyright Office guidance, an independent contractor who develops website material is generally considered the author and copyright owner unless the hiring party acquires the applicable exclusive rights through a signed written agreement. Because the outcome depends on the facts and contract language, ask an attorney to review important ownership or licensing questions rather than relying on a proposal, invoice, or verbal promise.
Downloadable-style website access inventory
Copy this table into a spreadsheet and complete one row for every website-related asset. Store the inventory in a secure location controlled by the business—not only in a vendor's project system or an employee's personal account.
| Asset or account | Provider and account URL | Business owner | Business admin email | Vendor access | Renewal or billing date | Payment owner | Recovery email or phone | MFA method | Export or backup location | Status or next action |
|---|---|---|---|---|---|---|---|---|---|---|
| Domain registrar | | | | | | | | | | |
| DNS management | | | | | | | | | | |
| Website hosting | | | | | | | | | | |
| Website platform or CMS | | | | | | | | | | |
| Source code repository | | | | | | | | | | |
| Deployment account | | | | | | | | | | |
| Google Analytics | | | | | | | | | | |
| Google Search Console | | | | | | | | | | |
| Google Business Profile | | | | | | | | | | |
| Business email admin | | | | | | | | | | |
| Form or CRM system | | | | | | | | | | |
| Call tracking | | | | | | | | | | |
| Online scheduling | | | | | | | | | | |
| Payment processor | | | | | | | | | | |
| Image and design files | | | | | | | | | | |
| Backup storage | | | | | | | | | | |
For each row, verify access by signing in rather than accepting “you have access” as an answer. Confirm that recovery messages reach a current business-controlled address or phone. Do not place passwords, recovery codes, or private keys directly in an ordinary spreadsheet; use a suitable password manager or another approved secure system.
1. Domain registration and DNS checklist
The domain is the address customers use to reach your website and often supports business email. Losing control can disrupt the site, email, forms, and customer trust even if the website files still exist.
[ ] The business is identified as the domain registrant or registered name holder where applicable.
[ ] The registrar account is controlled by a business email address, not a vendor's or former employee's personal email.
[ ] At least two authorized people know which registrar manages the domain.
[ ] Registration contact information is accurate and current.
[ ] The business can access renewal settings, billing records, domain lock settings, and DNS controls.
[ ] Auto-renewal and the payment method have been reviewed.
[ ] The expiration date is recorded in the ownership inventory.
[ ] Multifactor authentication is enabled when the registrar offers it.
[ ] Recovery email addresses, phone numbers, and backup codes are current and securely stored.
[ ] The business knows how to obtain the authorization or transfer code if it changes registrars.
[ ] DNS records have been exported, documented, or captured before a vendor transition.
ICANN states that registrants are entitled to information about managing, transferring, renewing, and restoring their domain registrations. It also says registrants are responsible for keeping account and payment information current. Domain control should therefore remain with the business even when a website provider handles day-to-day DNS work.
2. Hosting, platform, and website source code ownership
First identify what kind of website you are buying. A hosted website builder, a self-hosted content management system, and a custom application do not provide the same portability or source-code rights.
Hosting and platform access
[ ] The business knows where the production website is hosted.
[ ] The business has an owner, administrator, or equivalent role in the hosting or platform account.
[ ] Billing is visible, including recurring hosting charges and usage-based fees.
[ ] The business can add or remove vendor users without sharing passwords.
[ ] DNS, SSL certificate, server, database, storage, and deployment responsibilities are documented.
[ ] The contract explains whether the provider may suspend or remove the site for nonpayment.
[ ] The business knows what can be exported if it leaves the platform.
Source code and platform rights
[ ] The proposal and contract state whether the business receives ownership, an exclusive license, a nonexclusive license, or only platform access.
[ ] Custom code, templates, themes, configuration files, and database structures are addressed separately when necessary.
[ ] The business has appropriate access to the code repository if a repository is part of the project.
[ ] The repository is held in a business-controlled organization or has a documented transfer process.
[ ] The business has the level of access needed to manage collaborators, deployment settings, webhooks, and repository transfers.
[ ] Open-source and third-party components are identified with their licenses.
[ ] The contract states what happens to code if the relationship ends before the project is complete.
GitHub's current documentation, reviewed for this draft on August 26, 2026, distinguishes read, write, maintain, and admin repository roles. Organization owners have administrative access to repositories owned by the organization. If GitHub is used, simply being able to view or edit code is not the same as controlling repository access and transfer settings.
For a proprietary hosted builder, receiving its underlying platform code may be impossible or outside the service being sold. In that case, focus on clearly disclosed limitations, content and data exports, domain independence, media access, cancellation terms, and the practical cost of rebuilding elsewhere.
3. Google accounts, analytics, business email, and lead systems
A website is only one part of the business's online presence. Google Business Profile, analytics, email, directory listings, social profiles, and lead-management tools are separate accounts. Access to the website does not automatically provide access to any of them.
Google Business Profile
[ ] The business has primary owner access.
[ ] A second trusted business representative has an appropriate owner or manager role.
[ ] Each user has an individual Google Account; passwords are not shared.
[ ] Current and pending users have been reviewed.
[ ] Former vendors and employees have been removed after transition work is complete.
Google currently allows multiple Business Profile owners but only one primary owner. Owners can add and remove users, while managers cannot. This makes primary ownership an important business-control check rather than a job that should remain permanently assigned to an outside provider.
Analytics and measurement
[ ] The business knows which Google Analytics account and property collect website data.
[ ] At least one business-controlled account has the Administrator role.
[ ] The business can access Google Search Console and relevant verified properties.
[ ] Tracking IDs, tag-management accounts, conversion events, and advertising links are documented.
[ ] The vendor's access can be changed or removed without creating a new analytics property.
Google Analytics permits access at the account or property level and requires an Administrator role to add or modify users. Ask for business-controlled administration, not just emailed reports or read-only access.
Business email and lead systems
[ ] The business controls the email service's top-level administrator account.
[ ] Recovery details do not depend only on the website vendor.
[ ] Mailboxes, aliases, shared inboxes, forwarding rules, and retention needs are documented.
[ ] Website form notifications go to monitored business addresses.
[ ] Form submissions are stored or routed according to a documented process.
[ ] CRM, call tracking, scheduling, chat, payment, review, and advertising accounts are listed in the inventory.
[ ] API keys, webhooks, phone numbers, integrations, and automation ownership are documented.
[ ] The exit plan explains how historical leads and customer records can be exported.
Test the complete lead path: submit a form, place a tracked call, request an appointment, and confirm that the correct employee receives each inquiry.
4. Content, images, design files, licenses, and trust signals
Inventory the material customers see and the source files needed to update it.
[ ] The contract addresses ownership or licensing of website copy, photographs, video, graphics, logos, icons, illustrations, and custom design work.
[ ] The business has original-resolution images and editable design files when those files are included in the project scope.
[ ] Stock media licenses identify the license holder and any transfer or reuse restrictions.
[ ] Font, plugin, theme, template, and software licenses are documented.
[ ] Customer testimonials, case studies, certifications, team biographies, service details, and pricing statements have internal approval.
[ ] The business has permission to publish customer names, photographs, logos, or project details where permission is required.
[ ] Core business information—name, address or service area, phone number, hours, and website URL—is accurate and consistent across the website and important profiles.
[ ] The business can update essential trust signals without depending indefinitely on the original vendor.
Separate “we can display this on the current website” from “we can reuse, edit, transfer, or sublicense this elsewhere.” The contract and applicable license determine those rights.
5. Backups, security, and recovery checks
Access is not a recovery plan. A useful backup must contain the information required to restore the site, and someone must know how to use it.
[ ] Automated backup frequency is documented.
[ ] Retention periods are documented.
[ ] Backups cover the database, uploaded files, code, configuration, and other required components.
[ ] At least one recent backup is stored separately from the production environment when practical.
[ ] The business knows who can initiate a restore.
[ ] A restore or staging recovery has been tested at an agreed interval.
[ ] Encryption keys, deployment keys, API credentials, and recovery codes are securely controlled.
[ ] Multifactor authentication is enabled for critical accounts where available.
[ ] Access reviews occur after employee or vendor departures.
[ ] The incident contact list includes the registrar, hosting provider, website provider, email administrator, and business decision-maker.
Ask the provider to explain recovery in plain language: what is backed up, where it is stored, how long it is retained, who can restore it, and the likely process and cost. Avoid treating an untested claim that “backups are included” as sufficient.
6. Website vendor exit plan and contract questions
Agree on the exit process before the website launches. Negotiating access during a dispute or urgent migration is harder than documenting it at the start.
Questions to put in writing
Who owns each custom deliverable after payment?
Which components are licensed rather than transferred?
Which accounts will be opened in the business's name?
What administrator access will the business receive, and when?
What happens to the domain, hosting, code, content, images, database, and lead records at termination?
Which files and exports will be delivered?
Are editable design files and original media included?
Are there migration, cancellation, export, or early-termination fees?
How much notice must either party provide?
How long will the vendor preserve data after termination?
Who completes DNS, email, form, analytics, and integration changes?
How will confidential credentials and customer data be returned or destroyed?
What support is available during the transition, at what rate, and for how long?
Which third-party subscriptions must be replaced or transferred?
What happens if the vendor closes, is acquired, or can no longer provide service?
Vendor transition sequence
[ ] Review the signed contract and current invoices.
[ ] Create the full account and asset inventory.
[ ] Add business-controlled administrators before removing anyone.
[ ] Export content, leads, analytics configurations, DNS records, and other available data.
[ ] Take and verify a current website backup.
[ ] Confirm domain, hosting, email, and integration renewal dates.
[ ] Plan DNS and deployment changes to reduce avoidable disruption.
[ ] Test the website, forms, calls, email, analytics, and scheduling after migration.
[ ] Remove old vendor access only after required transition tasks are complete.
[ ] Rotate shared credentials, API keys, deployment keys, and recovery codes as appropriate.
[ ] Save final documentation, invoices, licenses, exports, and written confirmation of termination.
The goal is not to deny a provider the access needed to do its job. The goal is to ensure the business can continue operating, change providers, and recover from a problem without depending on one outside login.
Frequently asked questions
Who owns my business website if I paid a web designer to build it?
Payment alone does not answer every ownership question. The contract should state who owns or licenses the custom code, copy, images, graphics, and other deliverables. U.S. Copyright Office guidance says an independent contractor is generally the author and copyright owner of contractor-created website work unless the applicable exclusive rights are acquired through a signed written agreement. Review the agreement with a qualified attorney if ownership is unclear or disputed.
Should my website provider register the domain for me?
A provider can help with registration and DNS setup, but the domain should generally sit in an account controlled by the business, using current business contact and recovery details. Give the provider delegated access when possible instead of making its personal or agency account the only point of control. Record the registrar, registrant information, expiration date, payment method, recovery process, and transfer-code procedure.
Do I need website source code if I use a hosted website builder?
Not always. Proprietary hosted builders may not provide their underlying platform code, even when you control your pages and content. Before committing, ask what can be exported, whether the domain can be moved, which media and data you can download, how cancellation works, and what would need to be rebuilt elsewhere. For a custom-coded website, address repository access, source-code ownership or licensing, deployment files, database access, and transfer procedures in the contract.
Ready for a website built to generate local leads?
Talk with Foray Business Consulting about a clear, credible website designed around how local customers find and contact your business—including practical ownership, access, and launch-readiness planning.
