What a Property Owner Actually Receives at Website Handover

Most conversations about a small property website focus on how it looks the day it goes live. The expensive questions arrive months later, when an owner wants to change a phone number or move to a different host — and discovers nobody is sure who holds the login.

This is a checklist for the moment a website project ends. It is written for independent hotels, guesthouses, villas, rural stays and serviced apartments, but the logic applies to any small business site.

Handover is a transfer of access, not just files

A finished website is three things stacked together: the files that describe the site, the account that tells the internet where to find it, and the accounts that measure and manage it. A handover covering only the first leaves the owner dependent on whoever built it.

The rule worth applying: if the owner cannot log in and change something without asking the developer, the handover is not finished.

The checklist

1. Domain name

• Confirm which account the domain is registered in, and who the registrant contact is. Registrars send renewal and verification notices to that address.
• Make sure the owner controls that account, or has a documented path to recover it. A domain sitting under a developer's email is a single point of failure.
• Record the renewal date and the payment method attached to it. An expired domain takes the whole site offline.
• Note where the nameservers point. MDN's guide on publishing a website describes nameservers as the setting connecting a domain name to a specific hosting server — which matters every time hosting changes.

2. Hosting

• Identify the hosting provider, the account that pays for it, and the renewal terms.
• Confirm who can log in and through what mechanism — a control panel, FTP credentials, or deployment from a code repository. Each implies a different kind of access.
• Ask what happens if hosting lapses, whether a backup of the site files exists elsewhere, and where it lives.

3. Analytics accounts

This is the area most often left ambiguous. If a measurement tool was set up for the property, the property should own it.

Google's Analytics documentation explains that access is managed through defined roles — Administrator, Editor, Marketer, Analyst and Viewer — with Administrator holding full control, including managing users and granting permissions on any account or property beneath it. Two conclusions follow:

• The owner should hold Administrator, not Viewer. A Viewer can see data but cannot manage users, so a property stranded as Viewer cannot easily add or remove access later.
• Developer access should be granted as a specific role, not through shared credentials.

Google also notes that roles are inherited by default: an account-level role applies to every property in that account, and effective permissions are the most permissive role that applies. A developer holding Editor at account level effectively holds it across all properties there, not only the one they built.

4. Content editing

• Establish who can change text, photos and prices, and how. A site only a developer can edit turns a five-minute update into a support request.
• Agree which pages are safe for the owner to edit and which touch shared layout or navigation.
• If a content management system is used, confirm the owner's role is sufficient and no broader than necessary.

5. Third-party integrations

WUUS does not provide a property management system, booking engine or payment gateway. Where a site links to a booking engine, that engine is a separate account owned by the property or their provider.

• Confirm the booking engine account owner and whether the site's links point to the property's own account.
• Check the link destination is current. Booking engines change URLs, and a stale link sends guests nowhere useful.
• Note any widget or embed that depends on the booking provider staying active.

6. Documentation

A handover document does not need to be long. It needs to answer in one place: what accounts exist, who owns each, the renewal dates, and who to contact for what. Store it where the owner would find it if the original developer became unavailable.

7. Support window

Written agreements normally define a limited defect-support period after launch, with new content, new functionality and third-party outages handled separately. Confirm the end date so it does not pass unnoticed.

Where this fits in a WUUS project

WUUS is a website design and development studio working remotely from Jakarta, Indonesia. Each project begins with a written proposal covering pages, content, features, price, currency, external costs, estimated schedule, acceptance, cancellation and payment instructions. The published terms state that after final payment WUUS hands over the agreed source code and content, and that the property's domain and production hosting should sit in accounts the owner controls.

Two points worth stating precisely, because they are assumed rather than agreed:

• Ownership of the site is not ownership of everything. Third-party assets, fonts and libraries keep their own licences.
• Continuing costs are separate. Commercial hosting, domain renewals, integrations and ongoing maintenance are listed individually in the proposal rather than bundled into the project price.

Standard proposals also include 14 calendar days of support after launch for defects against the agreed scope. New content, new functionality and third-party outages fall outside it. Extensions or work beyond scope are a separate arrangement.

Analysis: why this checklist protects the property

The pattern behind most website disputes at small properties is not bad design — it is unclear ownership at the boundaries. Nobody intended for the domain to sit in a personal email account, or for analytics access to stay with a freelancer who moved on. It simply was never written down.

A handover checklist turns those boundaries into decisions someone made on purpose. For a property that may work with a web studio once and then run the site for a decade, that documentation is the difference between an asset and a dependency.

Frequently asked questions

Does handover mean I own the design? Ownership depends on the written agreement. WUUS hands over the agreed source code and content after final payment, while third-party assets keep their own licences.

Can I move the site to another host later? You should be able to, provided you control the domain account and have the site files — which is why domain and hosting accounts belong in the owner's name from the start.

Does this guarantee more bookings? No. Website delivery does not guarantee bookings, revenue or search rankings. The checklist is about control, not performance.

Ready to plan a property website with clear ownership from day one? Start from the WUUS proposals and service terms, then send your property details for a written scope: webuntukusaha.com/blog