Who Owns Your Website After the Designer Leaves?
The website is live. The designer hands over a login. Everyone calls the project complete.
Six months later, the credit card expires, a form stops reaching the right person, an employee needs access, the domain renewal notice goes to an old inbox, and nobody knows whether changing a page title will break search traffic. The business can see the website, but it does not fully control or operate it.
Website ownership means having a documented operating model for the accounts, decisions, content, data, and recurring care that keep the site useful. One password covers only a fraction of that responsibility.
The handoff should answer three questions for every critical part of the site:
Who owns it on behalf of the business?
Who performs the routine work?
Who provides specialist help when the work carries technical or strategic risk?
If the same person fills all three roles today, document them anyway. Roles change. The website should survive the relationship that launched it.
Separate the owner, operator, and specialist
The owner has business authority. This person controls the primary account, billing, recovery, and the decision to grant or remove access. Ownership should rest with a stable business-controlled identity, not an outside vendor's personal address.
The operator handles approved recurring work, such as updating hours, adding an article, reviewing form submissions, or replacing a staff biography. The operator needs enough access and instruction to do that work safely, but may not need billing, domain, or full-administrator control.
The specialist handles work that requires deeper design, development, analytics, search, accessibility, security, or platform knowledge. Specialist access should be individual, appropriately limited, and removable without threatening business ownership.
Squarespace reflects this distinction in its own permission model. A site owner can invite contributors and assign permission levels, while ownership transfers and domain ownership changes follow separate processes. That is a useful reminder for any platform: site editing, site ownership, and domain ownership are related, but they are not the same control.
Map every part of the ownership chain
Create a website ownership register. It can be a controlled spreadsheet or document, but it should be stored somewhere the business can reach without the website vendor.
Business and platform account
Record the site owner, account email, billing owner, renewal method, recovery path, plan level, support route, current administrators, and last access review. Do not store passwords in the register. Use an approved password manager and document who controls the vault or recovery process.
Domain and DNS
Record the domain registrar, registrant or domain owner, renewal status, billing contact, administrative access, nameservers, and DNS owner. The domain is the address people use to reach the site. Losing control of it can affect the website, email, and other services tied to DNS.
Do not casually edit DNS records during a site update. First record the existing state, understand which services each record supports, and establish a rollback path.
Content management system
List roles and permissions, not shared credentials. Note who can publish, change design settings, install integrations, manage commerce, view customer data, or alter custom code. Review inherited access from former employees, agencies, contractors, and test accounts.
Content and media
Identify the owner of page copy, articles, service information, legal pages, downloadable files, photographs, illustration, video, and source design assets. Record usage rights and expiration when relevant. A file being present in the media library does not prove the business has permission to reuse it forever or everywhere.
Forms and customer data
Trace each form from submission to destination. Record the form owner, notification recipients, storage location, required privacy notice, retention decision, integration, test method, and response owner. Include newsletter, contact, application, quote, event, download, and purchase paths.
Submit a real test through the public page. Confirm the customer sees the expected response, the data reaches the correct controlled system, the responsible person receives a useful notification, and the record can be found later.
Search, analytics, and AI access
Record ownership and verified access for Search Console, analytics, tag management, business profiles, advertising connections, consent tools, and any reporting destinations. Define the important conversions and the person responsible for checking whether collection still works.
Google describes Search Console as a tool for monitoring and troubleshooting a site's presence in Google Search. Linking Search Console and Google Analytics can help connect search discovery with on-site behavior, but the accounts and measurement definitions still need a business owner.
AI visibility introduces another access layer. OpenAI explains that publishers can use OAI-SearchBot controls in robots.txt to manage whether sites appear in ChatGPT search results. That is separate from the controls for model training. The useful business decision is not "turn on AI SEO." It is to decide which public content should be discoverable, make that content clear and supportable, document crawler rules, and verify that technical controls match the decision.
Integrations and custom behavior
List scheduling tools, customer systems, email platforms, payment services, maps, feeds, scripts, pixels, embeds, and automations. For each connection, record its business purpose, account owner, data exchanged, failure signal, and removal consequence.
Custom CSS or JavaScript needs an owner, a reason, a location, and a test. If nobody can explain what a snippet does, do not delete it in production to find out. Inspect it, preserve the current state, test the effect safely, and document the decision.
Define what the business may change safely
A handoff should not force the business to choose between total dependence and unrestricted editing.
Create three change levels.
Routine changes are repeatable and low risk when made by a trained operator. Examples might include correcting approved text, updating hours, replacing an image within an established component, or adding an article through a documented template.
Reviewed changes can affect several pages, customer behavior, brand consistency, accessibility, or measurement. Examples include changing navigation labels, creating a new form, altering a page layout, adding a campaign landing page, or changing an integration.
Specialist changes can affect domain service, security, code, data, search visibility, site-wide design, checkout, privacy, or publication state. They need a qualified person, a backup, a test plan, and a rollback path.
The categories should reflect the actual platform and business. Their purpose is to create confident action at the routine level and healthy friction where mistakes have wider consequences.
Make the handoff performable
A folder full of screen recordings fails the handoff when nobody can use them under ordinary pressure. Run a live drill with the future operator.
Ask that person to:
Sign in through the business-controlled route.
Find the site owner, billing status, and support path.
Identify the domain registrar and renewal owner.
Make one routine content update in a safe context.
Preview it at relevant screen sizes.
submit a public form and trace the result.
Find the analytics or search account and explain one meaningful measure.
Identify how to restore or reverse the test change.
Remove a test contributor or explain who has authority to do it.
Find the current operating document without asking the designer for a private link.
Observe the friction. If the operator can complete a task only while the designer narrates every click, the handoff is not yet self-sustaining.
Documentation should use the current interface, exact account names, decision boundaries, and expected result. Add a verification date and owner. Platform interfaces change, so stale instructions should be easy to identify rather than trusted indefinitely.
In my Web & Digital work at Parker Lee Creative, the handoff is part of the design. I plan for the people who will publish, approve, measure, and maintain the site after launch. That includes clear account ownership, understandable components, tested customer paths, limited access, and documentation that supports the next decision.
Protect the site from post-launch drift
Websites usually deteriorate through accumulation. A temporary alert becomes permanent. A new page ignores the heading order. An old form continues sending to a departed employee. Tracking breaks after a domain or consent change. Images grow heavier. A plugin, embed, or script remains after its business purpose ends.
Use a recurring operating rhythm.
Monthly or campaign-based checks
submit critical forms and inspect the complete response path
review obvious broken links and public errors
confirm current offers, dates, hours, people, and contact details
inspect important conversions and unusual measurement gaps
review new content on mobile and with keyboard access where relevant
Quarterly governance review
audit contributors, administrators, vendors, and connected applications
confirm domain, platform, and critical-service renewal ownership
review content that is stale, duplicated, unsupported, or no longer useful
check the highest-value pages in search and analytics tools
inspect Core Web Vitals and other performance evidence using appropriate tools
review integrations, custom code, privacy notices, and data routes
update the ownership register and operating instructions
Google's web.dev documentation lists field and lab tools for assessing Core Web Vitals, including Search Console, PageSpeed Insights, Chrome DevTools, and the Chrome UX Report. No single score replaces judgment. Use the evidence to locate real experience problems, then test the affected pages and devices.
Annual continuity exercise
Pretend the current designer, administrator, or lead employee is unavailable. Can the business renew the domain, change billing, recover the account, reach support, export important information, remove old access, and authorize a new specialist? The exercise turns a vague dependency into a repairable list.
Know what a responsible designer should leave behind
A strong website handoff includes more than credentials:
a verified ownership and access register
current site and domain account control
role-based contributor access
a page and content inventory
form and data-flow documentation
analytics and search ownership
integration and custom-code notes
rights and source-asset status
routine publishing instructions
change-risk boundaries
backup, export, and rollback information
an open-issues list
a maintenance rhythm and decision owner
The exact package should match the project. A simple informational site needs less operational machinery than a site with commerce, memberships, applications, multiple integrations, or sensitive data. Simplicity is good when it reflects lower complexity, not missing ownership.
Before the project closes, assign a business owner to every item in the handoff package and schedule the next verification date while current access and context are still available.
