Hiring technical expertise makes delegation natural, but setup assistance must not mean surrendering business assets. Your domain, source code, database, design files, and analytics account belong to you as a matter of business continuity and legal right, not courtesy.
Ownership problems often begin as convenience: developer-owned domain, hosting, and analytics accounts. Three years later, switching developers/hosts or selling reveals someone else controls supposedly owned assets. This guide prevents that dependency.
Why website ownership is not automatic
Payment alone doesn't convey US copyright. Creators retain it by default; employee work-for-hire transfers to employers, but freelancers/agencies need explicit written IP assignment. Fully paid code can still belong to its developer.
Domain registration differs from copyright. The registrant controls nameservers, DNS, and renewal. Developer-account registration makes them registrant; your CMS admin name doesn't confer domain ownership.
Hosting is separate again. WordPress content access doesn't provide full files, host migration, or developer handoff. These three access levels often become clear only during disputes, unresponsiveness, or server failures.
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
Domains carry brand, SEO history, backlinks, and accumulated search trust. Losing one is worse than losing the site: code can be rebuilt, but established domain history cannot be replaced on useful business timelines.
Use your registrar account/email/payment method. Namecheap, Cloudflare Registrar, and Google Domains are reliable; ownership matters more. Account owners control nameservers, DNS, WHOIS, transfers, and renewal.
Delegate DNS management for web, email, and CDN settings through registrar permissions. Developers can perform technical work without owning the account; this is the appropriate arrangement.
Request developer-account domain transfers while relations are good. Allow 5–7 days and the receiving registrar's annual renewal fee: unlock, obtain authorization code, accept transfer. Adversarial transfers are slower and obstructed more often.
Check now: Go to whois.domaintools.com and enter your domain. The registrant contact information shows who the domain is registered to. If it shows your developer's name or an email address you do not control, that is the first thing to fix.
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.
Own-account hosting provides direct cPanel, Hetzner Cloud, DigitalOcean, or Cloudways credentials and billing. Developers configure/deploy on your behalf; disappearance doesn't stop the site, and replacements receive access without permission. This is cleanest.
Developer-managed hosting legitimately bundles maintenance, SSL renewal, patches, nightly backups, and uptime for competitive monthly fees. Test portability: timely source/database exports and explicit offboarding to your host. Clear agreement demonstrates service; evasion or friction suggests leverage.
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
Receive actual PHP, HTML, CSS, JavaScript, configuration, images, and other source assets, not dashboard/view-only access. Delivery can be GitHub/GitLab owner/collaborator access or a zip archive.
Source files make the site portable: any PHP developer can understand and continue it. Code confined to a developer's server/private repository leaves only access to a running service, not ownership of the underlying asset.
Source enables second-developer features, accurate maintenance quotes, buyer IP/architecture due diligence, and restoration after server failure. Backups must contain 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.
Custom PHP handoff includes router, templates, includes, styles, and database schema. WordPress needs wp-content themes/plugins, database export, and wp-config.php. Check the complete set for your project type.
Your database and data exports
Stored forms, clients, bookings, orders, and accounts belong to you, not developer/host. Require full SQL export anytime, without tickets, waiting, or extra fees.
In three years, replacement developers need database structure/data for migration. Hosting moves export/import it. Independent backups require exporting to storage you control.
Developer/host-only backups leave data on someone else's infrastructure. Compromise, RAID failure, mistaken suspension, or data-center outages can destroy access. Independent exports provide recovery; others rely on potentially days-old backups, if available.
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.
If you cannot export your database without asking the developer, that is a dependency worth resolving. Either get direct hosting access that lets you run exports yourself, or ensure the contract specifies regular backup delivery to your storage.
Design assets and source files
Keep editable source files for your custom logos, illustrations, icons, brand photos, and other visual assets. Website PNG exports alone do not let you or future designers work directly with the originals.
Keep SVG, AI (Adobe Illustrator), or EPS logo sources. Fixed-resolution PNGs cannot scale losslessly for print ads, banners, app icons, or slides. Web-only rasters force avoidable paid recreation.
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.
Identify stock images and license restrictions by site, resolution, and use. Web-to-print reuse or new-domain use after expiry can trigger copyright claims. Obtain license receipts at handoff or license through your own stock account.
Retain favicon files (16x16/32x32 PNG, .ico, ideally SVG), 1200x630 Open Graph sharing images, and Figma/equivalent design documentation. Exact colors, type scales, spacing tokens, and component states let future developers extend branding consistently rather than compound visual drift.
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.
Historical traffic, sessions, and conversions become increasingly valuable baselines. Developer-account access loss erases the record: the next six months lack context, successors can't compare their changes, and seasonality stays hidden until another full year passes.
Google Search Console reports crawl/indexing errors, speed/stability, and search queries; it also accepts XML sitemaps and verifies ownership for Google services. Losing access removes your direct technical-health communication channel.
Own payment accounts tied to your entity/bank, plus email marketing, CRM, scheduling, and other integrations; add developers as users. Developer-account API keys create silent dependencies that fail if they close accounts or stop paying.
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
A common trap: developer-owned domains/agency hosting, WordPress admin-only access, Google Analytics/Search Console in developer accounts with shared dashboards. Nameservers, including email-routing MX records, remain theirs. Clients see a working site for months/years without controlling its underlying infrastructure or data properties.
Fee increases, disputes, closure, or unresponsiveness expose the trap. Developer-controlled nameservers/hosting can take site/email down; renewal and migration require cooperation. Three years of Analytics vanish, Search Console monitoring/sitemaps remain inaccessible, and developer-Stripe payments stop when API access is revoked.
Cooperative transitions commonly cost $500–$2,000 plus successor setup: DNS, hosting, files, database, credentials, Search Console, and changed-URL 301 audits. Unresponsive developers may require ICANN Uniform Domain-Name Dispute-Resolution Policy (UDRP): minimum $1,500 filing, 45–90 days, documented rightful ownership. Without contractual ownership, proof becomes legal work. A $15-a-year domain becomes a multi-thousand-dollar recovery.
Request transfers while relations work: domain to your registrar, source files, database export, direct hosting, Search Console/Analytics to your Google account, and delegated nameserver control. Professional developers consider these routine; resistance reveals the arrangement's risks.
The fix is the same whether you are pre-project or mid-relationship: make code delivery, domain ownership, and data access named deliverables in writing before work starts. Not after the project is done. Not if you think to ask. Named deliverables with a handoff checklist attached to the final payment milestone.
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 alongside 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.