Website ownership: the complete guide to what you should control — and how to get it

When you hire a developer to build your website, the instinct is to hand everything over and let them handle the details. That is understandable. You hired them because they know things you do not. But there is a difference between delegating technical setup and ceding control of assets that are fundamental to your business. The domain name, the source code, the database, the design files, the analytics account: these things belong to you. Not as a matter of courtesy — as a matter of business continuity and legal right.

Most ownership problems do not start as bad faith. They start as convenience. A developer registers the domain in their own account because they already have a registrar login open. They put the hosting on their server because it is simpler to manage. They leave the analytics property in their agency account because that is where they set up all their clients. At the time, it feels like they are doing you a favor by handling the details. Three years later, when you want to switch developers, move to a faster host, or sell your business, you discover that the assets you thought were yours are controlled by someone else. This guide is about preventing that.

Why website ownership is not automatic

Paying for a website does not automatically mean you own everything that was built for it. Copyright law in the United States gives the creator of a work ownership of that work by default. For employees, the work-for-hire doctrine transfers copyright to the employer. For independent contractors — which describes most freelance developers and agencies — copyright stays with the creator unless the contract explicitly transfers it to the client. You can pay the invoice in full and still not legally own the code if the contract does not include a written IP assignment clause.

Domain registration is separate from copyright entirely. Whoever registers the domain is the registrant on record with the domain registry. The registrant controls the domain's nameservers, DNS records, and renewal. If a developer registers your domain under their account, you are not the registrant — they are. Your name in the admin panel of some CMS does not make you the domain registrant.

Hosting access is a third distinct question. Being given a WordPress admin login is not the same as having access to the hosting environment where the site lives. Being able to log in and edit content is not the same as being able to export the full site files, move the installation to a different host, or take the code to a different developer. These are three entirely different levels of access, and most clients discover the distinction at the worst possible time — when the developer is unresponsive, the relationship has soured, or something has gone wrong with the server.

Understanding what you are entitled to, and ensuring it is written into the project agreement before work starts, is the difference between owning a business asset and renting access to one.

Your domain: registered in your name

Your domain name is the single most important asset attached to your online presence. It carries your brand, your SEO history, every backlink that has ever pointed to your site, and the trust signals that search engines have built around your URL over time. Losing control of the domain is worse than losing control of the website itself. A site can be rebuilt. The history attached to a specific domain name cannot be replaced on any timeline that matters to a running business.

The domain should be registered in a registrar account that you own, with your email address and your payment method on file. Namecheap, Cloudflare Registrar, and Google Domains are all reliable options, but the choice of registrar matters far less than whose account the domain lives in. The registrar account owner controls everything: nameserver configuration, DNS records, WHOIS contact information, transfer eligibility, and renewal.

It is entirely legitimate for a developer to manage your DNS records on your behalf. DNS management means logging into your registrar account to configure where the domain points — to your web server, your email provider, your CDN. DNS management access can be granted to a developer through registrar-level delegate access without giving them account ownership. That is the right arrangement: you own the account, the developer has access to do the technical work.

If a developer registered your domain in their own account, ask for a transfer now. Domain transfers generally take 5 to 7 days and cost nothing beyond the receiving registrar's annual renewal fee. The process involves the losing registrar unlocking the domain and providing a transfer authorization code, and the gaining registrar accepting the transfer. Do this while the relationship is still good. Transfers that happen under adversarial conditions are slower and more likely to encounter obstruction.

Hosting: your account or legitimate managed hosting

Hosting is where your site's files physically live: the server that responds when someone's browser requests your URL. Hosting control is a separate question from domain control. Two legitimate arrangements exist, and understanding the difference between them matters because they have different implications for what happens when you want to change developers or move to a different server.

Hosting in your own account means you have direct login credentials to a hosting panel — cPanel, Hetzner Cloud, DigitalOcean, Cloudways, or similar. You are paying the hosting bill directly. The developer deploys to your server and configures it on your behalf, but the account is yours. If the developer becomes unresponsive tomorrow, your site keeps running. If you want to hire a different developer, you can give them server access without any involvement from the original developer. This is the cleanest arrangement.

Managed hosting through the developer is also legitimate. Many professional developers run client sites on their own server infrastructure and charge a monthly fee that covers server maintenance, SSL renewal, security patching, nightly backups, and uptime monitoring. That is a genuine service with real value, and the pricing is often competitive with what you would pay for a managed hosting plan plus the time to manage it yourself. The critical test for any managed hosting arrangement is portability: if you decide to leave, can you get the source files and database export within a reasonable timeframe and move to your own host? A professional developer answers yes without hesitation and specifies what the offboarding process looks like. If the answer is unclear, evasive, or involves significant friction, the managed hosting arrangement is functioning as leverage rather than as a service.

The question to ask before any project starts: "If you went out of business tomorrow, what would happen to my site?" The answer to that question reveals the actual ownership structure, whatever the contract language says.

Source code and file delivery

At project completion, you should receive the complete source files for your site. Not a login to a dashboard. Not view access to a hosted version. The actual code: PHP files, HTML templates, CSS stylesheets, JavaScript, configuration files, images, and any other assets that make the site work. This comes through a GitHub or GitLab repository where you are an owner or collaborator, or through a zip file delivered directly to you.

Source file ownership is what makes your site a portable business asset rather than a service subscription. When you have the source files, any PHP developer in the world can open them, understand the structure, and continue working on the site without starting over. When the code lives only on the developer's server or in their private repository, you have access to the running website — but you do not have the underlying asset. That is the difference between owning a building and leasing office space in it.

Code portability has concrete business implications. If you want to bring in a second developer for a specific feature, you need the code. If you want to get a quote from a different developer for maintenance work, they need to see the code to give you an accurate estimate. If you sell your business, the buyer's due diligence will ask about IP ownership and want to inspect the technical architecture. If you need to rebuild from a backup after a server failure, the backup needs to contain the actual files.

Code delivery should be a named deliverable in the project contract, not something that happens if you think to ask for it at the end. "I can get you the files if you need them" is not the same as having the files. By the time you need them and the developer is unavailable, the distinction matters enormously.

For sites built on custom PHP, the file set includes the router, page templates, includes, stylesheets, and any database schema files. For WordPress sites, it includes the wp-content directory (your theme and plugins), the database export, and the wp-config.php. Knowing what constitutes a complete handoff for your specific project type lets you verify that you actually received everything, not just most of it.

Your database and data exports

If your site uses a database — for contact form submissions, client records, appointment bookings, order history, user accounts, or any other persistent data — that data is yours. Not the developer's. Not the hosting provider's. Yours. And you should be able to export a full SQL dump at any time, without opening a support ticket, without waiting for someone to respond, and without being charged for the privilege.

The practical reasons this matters are straightforward. If you switch developers three years from now, the incoming developer needs the database to understand the data structure and migrate it to a new environment. If you switch hosting providers, the database comes with you in export format and gets imported on the new server. If you want to run your own backups independently of whatever the developer or host is doing, you do that by exporting the database to a location you control.

Relying solely on the developer's backups or the hosting provider's backup system means you have one copy of your data in someone else's infrastructure. Hosting providers have catastrophic failures. Servers get compromised, RAID arrays fail, accounts get incorrectly suspended, data centers experience outages. When a developer's managed hosting environment goes down with no prior notice, the clients who had their own independent database exports have a path to recovery. The ones who did not are starting from a backup that may be days old, if one exists at all.

A good rule: export your own database at least quarterly and store it somewhere you control — a cloud storage service, a local drive, both. It is a 5-minute task for someone with hosting or database access, and it is the single most concrete form of data ownership you can exercise.

Design assets and source files

Logos, custom illustrations, icon sets, brand photography, and any other visual asset created specifically for your business should be in your possession in source format. Not just the exported PNG that appears on your website — the actual editable source file that lets you or any future designer work with the asset directly.

For logos, that means the vector source: an SVG file or an AI (Adobe Illustrator) or EPS file. A PNG is a rasterized output at a fixed resolution. When you need the logo at a different size — for a print ad, a trade show banner, an app icon, a presentation slide — the only way to scale it without quality loss is from the vector source. If all you have is a PNG at web resolution, whoever works on it next has to recreate it from scratch, which is billable work that should have been unnecessary.

For design work done in Figma, Sketch, or Adobe XD, request a file export or at minimum view access to the original design files. Design files contain the intent behind every spacing decision, color choice, and typographic selection. Future developers who modify the site benefit from having that context rather than reverse-engineering it from the built output.

Stock photography is a separate consideration. If the developer licensed stock images for the site, you need to know which images are licensed and under what terms. Most stock licenses are site-specific, resolution-specific, or restricted by use type. Using a licensed image beyond the terms of its license — putting a web-licensed image in print, or using a licensed image on a new domain after the original license expires — exposes you to a copyright claim from the image provider. Ask for the license receipts at project handoff, or ask for the images to be licensed in your own stock provider account.

Web-specific design assets that often get overlooked at handoff: the favicon set (the small icon that appears in browser tabs, at minimum a 16x16 and 32x32 PNG plus an .ico file, ideally an SVG), Open Graph images (the 1200x630 images that appear when someone shares a page on social media or in a messaging app), and the design system documentation from Figma or equivalent. The design system matters because it records your exact color codes, type scale, spacing tokens, and component states — information a future developer needs to add new pages consistently without inventing their own interpretation of your brand. Without it, every new page that gets built after the original handoff risks introducing visual inconsistencies that compound over time.

Analytics, Search Console, and third-party credentials

Google Search Console and Google Analytics should be configured in a Google account that you own, with the developer added as a delegated user or property manager during the project. This is not a preference — it is a structural requirement for long-term ownership of your site's performance data.

Analytics data is cumulative. Traffic trends, conversion events, and session data become more valuable the longer they accumulate, because the historical baseline is what every future period gets compared to. If that data lives in the developer's Google account and they terminate your access — for any reason, including reasons unrelated to your relationship — you lose the entire record and start over from zero. That is not just an inconvenience. It means the next six months of data have no context, the next developer cannot audit what changed after they took over, and any seasonal traffic patterns are invisible until a full year has passed.

Google Search Console is especially important. It is where Google reports crawl errors, indexing coverage issues, page-speed and stability health checks, and which search queries are sending traffic to your site. It is also where you submit your XML sitemap and verify domain ownership for various Google services. Losing Search Console access is losing your direct communication channel with Google about your site's technical health.

Beyond analytics, every third-party account that powers functionality on your site should be in your name. Payment processors tie to your legal entity and bank account and should never be in a developer's account — this is non-negotiable. Email marketing platforms, CRM integrations, scheduling software, and any other service your site connects to should be accounts you own with the developer added as a user. API keys the developer generates from their own service accounts create silent dependencies: if they stop paying for the service or close their account, the integration breaks without warning.

A complete project handoff includes documented credentials for every third-party account the site depends on, with those accounts confirmed to be in your name. Not most of them. All of them.

The leverage trap: how it happens and how to get out

Here is the specific pattern that plays out in web development often enough to be worth naming directly. A developer registers the domain in their company account because they already have a registrar login open. They set up hosting under their agency plan and give the client a WordPress admin login, which feels like access to the website but is actually access to the content management layer sitting on top of the real site infrastructure. They configure Google Analytics and Search Console under their own Google account and share a reporting dashboard that shows the client their data without the client actually owning the property. Nameserver control stays with the developer, meaning they control where the domain points, including the mail server records (MX records) that route the client's business email. The client has a live website and the impression that everything is in order. For months or years, it works fine.

Then something changes. The developer raises their monthly maintenance fee. The relationship deteriorates over a scope dispute. The developer goes out of business, stops responding, or restructures their client base. What happens next depends entirely on who controls the nameservers. If the developer controls the nameservers and they stop paying for the hosting account, the site goes dark along with the business email routing through those MX records. The business owner cannot renew the domain without going through the developer. They cannot migrate the site without asking for a file export. Three years of Analytics data becomes inaccessible. The Search Console property was never transferred, so they cannot monitor crawl errors or submit a new sitemap. The payment processor running through the developer's Stripe account stops processing as soon as the developer revokes API access.

Getting out of this situation has a specific cost structure. If the developer cooperates, a full transition typically runs $500 to $2,000 in transition fees plus the cost of a new developer doing the setup work: DNS migration, hosting account setup, file transfer, database import, credential transfer, Search Console property migration, and 301 redirect audits on any URLs that changed during the move. If the developer is unresponsive, domain recovery through ICANN's Uniform Domain-Name Dispute-Resolution Policy (UDRP) costs a minimum of $1,500 in filing fees and takes 45 to 90 days, assuming you can document that the domain rightfully belongs to your business. If there is no written contract that establishes you as the intended domain owner, the documentation burden becomes a legal question. What was a $10-per-year asset at registration becomes a multi-thousand-dollar recovery project.

If you are currently in a situation where some or all of these assets are not in your control, the path forward is the same regardless of whether it happened by design or by convenience: make the request while the relationship is still functional. Request a domain transfer to your registrar account. Request the source files. Request a database export and direct hosting access. Request Search Console and Analytics properties to be transferred to your Google account. Request nameserver control to be delegated properly. Professional developers treat these requests as completely routine, because they are. Resistance to any of them tells you something important about the arrangement you are in.

Key takeaways

• Paying for a site does not automatically transfer ownership. Copyright law defaults to the creator. An explicit IP assignment clause in the contract is required to make ownership transfer legally enforceable.
• Your domain must be registered in your account, full stop. DNS management access can be delegated to a developer. Domain registration itself cannot. Use WHOIS to verify who the registrant is right now.
• Managed hosting through a developer is legitimate — with one condition. You must be able to get your source files and database export and move to your own host if you want to. If that is not possible, it is not a service arrangement, it is a dependency.
• Source file delivery should be a named deliverable in the contract. You receive either a GitHub repository or a complete file archive at the final payment milestone. Access to a dashboard is not a substitute.
• Analytics and Search Console go in your Google account. Historical data that accumulates in a developer's account is inaccessible to you if the relationship ends. Own the properties and add the developer as a user.
• Design source files matter as much as code files. Vector sources for logos and editable design files for layouts belong in your possession, not just the exported PNGs that appear on the live site.
• Request a complete credential handoff at project close. Every third-party account the site depends on should be confirmed in your name before you sign off on final delivery.