You can open your website, read the pages and send somebody its address. That proves the public site is available. It does not tell you who can renew the address, edit the content, recover a backup or help when the usual contact is unavailable.
A useful website handover record answers those questions before they become urgent. It is not a shared document filled with passwords. It is a clear map of the services, permissions, files and evidence that an authorised person needs to keep the site working.
The important distinction is between seeing the website and being able to look after it. A public page provides the first. A dependable arrangement with documented responsibilities provides the second.
Start with the four things people often call the website
The domain is the address people use. Hosting is the service that runs the site. The content system may provide a place to edit pages. The artwork and content files may live somewhere else again.
Those parts can be supplied together, but they do not become the same thing. Knowing the company that hosts the pages does not automatically tell you who holds the domain registration account. Being able to edit text does not automatically give you a recoverable copy of the site.
Write down the parts separately. Include the domain provider, the hosting or platform provider, the editing system and the location of approved content and artwork. For each, name the business contact or authorised person who can answer questions about it.
Do not guess from a familiar logo on an invoice. If the invoice describes several services, ask which account and responsibility belongs to each. A provider may manage a service on your behalf while another organisation operates it.
The record's first job is making those relationships understandable. It does not need to be an elaborate technical diagram to be useful.
Record control without putting credentials in the ordinary handover
For each service, ask who is authorised to manage it, how access is granted and what happens if that person leaves or cannot be reached. Record the secure recovery route and where protected access information is held. Do not paste the password, recovery codes or transfer authorisation code into the general project notes.
ICANN's Security and Stability Advisory Committee published a registrant-account protection guide in 2010. Among its lasting recommendations are identifying authorised contacts, keeping credentials protected, establishing recovery responsibilities and maintaining provider contact information. SAC044: protecting domain registration accounts
The date matters. It is a source for control and recovery principles, not a current instruction sheet for a particular registrar's buttons or every modern security setting. Your provider's current arrangements need their own confirmation.
Ask for access appropriate to each person's role. The person updating opening hours may not need permission to change domain settings. A specialist recovering a site may need a different level of access, granted through the provider's approved process.
The useful handover describes those roles. It should not make every future action depend on distributing one shared master login to whoever is available.
Put renewals and responsibility beside each other
An expiry date is more useful when somebody is responsible for acting on it. Record the service being renewed, the provider, the relevant business contact, how notices arrive and who checks them.
Do not assume that automatic renewal removes the need for a responsible person. Ask how the provider handles failed payments, changed contact details or a notice that needs a response. Record what has actually been confirmed rather than choosing a reassuring status from habit.
The same applies to a service sold through an intermediary. If your designer renews a domain on your behalf, the record should explain that arrangement and the contact route. If the business manages it directly, the record should say that instead.
A useful line might read: domain renewal managed by the business's authorised account holder; notices checked by the named business role; provider support route recorded; next review date confirmed. That is an illustrative structure, not a recommended entry for an account you have not inspected.
The record should make responsibility visible without exposing account secrets or payment information. You need to know where the obligation sits, not reproduce every sensitive detail on a page that circulates widely.
Find out what an editable copy actually contains
An image of a webpage is a useful reference. It is not an editable page source. A collection of photographs may help with a new layout. It is not necessarily the complete website.
Ask which content can be exported and which files are needed to edit or rebuild the work. The answer depends on how the site was made. A hosted platform may use a different handover method from a site running on a server you can manage.
Keep the approved text and original business images in a location the business can access through an authorised account. Record where editable design files, logo versions and other commissioned material are held, and which deliverables the agreement actually includes.
An agreement to publish a design does not automatically answer every question about source files, third-party assets or future transfer. Confirm the scope in the project terms rather than assuming that a folder called final contains all rights and all materials.
If some part cannot be exported in a reusable form, record the limitation plainly. That does not necessarily make the platform unsuitable. It changes what a future replacement or migration would involve.
A content export and a backup answer different questions
A content export can help move information into another system. A backup is intended to support recovery. Neither should be judged by its filename alone.
For WordPress specifically, the official administration handbook explains that a complete backup needs both the site's files and its database. WordPress backup guidance
That example should not be treated as a universal file recipe for every website. It demonstrates why the question needs to be precise. Ask your provider what is included for your own system, what is excluded and how the backup would be restored.
Record the date, the person or service responsible, the storage arrangement and the evidence that recovery is workable. If nobody has checked restoration, write restoration not yet verified. A successful backup notification and a successful restoration are different pieces of evidence.
Do not test recovery by overwriting the live website. Agree a safe test environment and a bounded process with the responsible specialist. The purpose of the rehearsal is to learn whether the arrangement works without turning the test into the incident you were trying to avoid.
Do not lose email while talking only about webpages
The business may use an email address on the same domain. The email service may be supplied by the host, by the domain provider or by another company. Record it as its own service.
Ask the person planning a change to identify which settings support the website and which support email. Do not assume that changing a domain provider, moving hosting or cancelling a package affects only the visible pages.
The handover should list the mail provider and responsible contact, and flag the need for a specialist check before connected services are changed. It does not need to include mailbox contents or private correspondence.
A useful project instruction is: confirm the effect on the existing website and email arrangements before making any change. That is a planning requirement, not a claim that every domain transfer causes an interruption.
Other connected services can deserve similar attention. Forms may deliver enquiries elsewhere. A booking function may depend on a separate account. An embedded map or payment feature may have its own provider. Record only the dependencies that actually exist; do not create a frightening inventory of hypothetical problems.
A domain transfer is not a handover shortcut
Sometimes a project requires changing the registrar that manages a domain. Sometimes it requires only giving an authorised person appropriate access or obtaining a clear record. Those are different actions.
ICANN maintains a transfer-policy resource for covered domain registrations and registrars. It includes the updated policy introduced through the Registration Data Policy implementation timetable. The current rules and provider process should be checked for the particular domain before a transfer is planned. ICANN's domain transfer resource
Do not apply a generic-domain policy automatically to every country-code domain, including an Irish .ie address. Confirm the applicable registry and provider requirements. Nor should a guide to organising a website become an instruction to unlock or move a domain immediately.
First establish the current arrangement, the required outcome and the people authorised to act. Then let the responsible provider or specialist explain the appropriate process and its timing. If a proposed transfer is unnecessary to the project, the record may resolve the confusion without it.
Keep the transfer codes and sensitive account information within the approved secure process. The ordinary handover record should say who can arrange the action, not contain a ready-made route for any reader to perform it.
Ask about the right to keep using the assets
A website may contain commissioned photographs, licensed fonts, stock images, plug-ins or other third-party material. Having a copy of a file does not by itself explain the permission to use it.
Record the source and the relevant licence or agreement for material that matters to the site. Ask whether a subscription belongs to the business or the provider, whether it can continue after a handover and what conditions apply to changing platforms or reusing the asset elsewhere.
Do not replace unknown rights with assumptions. Mark a missing licence or unclear deliverable as a question to resolve. Equally, do not describe all third-party material as unusable: the task is identifying the actual terms.
For business-owned photographs and commissioned artwork, record the approved version and the agreed uses where those have been confirmed. Customer images and testimonials need their own appropriate publication permission; a website handover does not silently expand it.
These records help prevent a later designer from having to choose between guessing and rebuilding material unnecessarily. They also make the scope of the new job clearer.
Use a short evidence matrix
Give each important part of the site one line with four answers: what is it, who is responsible, what evidence is available and what remains unresolved?
For the domain, the evidence may be an authorised account review or written provider confirmation. For content, it may be a dated export that somebody has opened and inspected. For a backup, it may be a documented safe restoration test. For a licensed image, it may be the source and licence record.
Avoid a single yes beside website access. It hides too many different meanings. Somebody can have access to a page editor without controlling hosting. Somebody can control hosting without holding the business's domain account. The matrix should reveal those distinctions.
Use plain unresolved labels. Provider confirmation pending is more informative than done when no confirmation exists. Backup stored; restoration untested is more informative than backup verified when only the file was copied.
Assign each unresolved item a person and a next step. The record becomes useful when it can move a question towards evidence, rather than merely collect a list of worries.
Rehearse the handover with a small real task
Ask an authorised second person to use the record for an ordinary task, such as locating the current approved logo or identifying who receives a renewal notice. Keep the rehearsal within their existing permission.
They should be able to find the correct source and contact without relying on the original designer's memory. If the record says files in shared folder, check that the named location exists and the authorised person can open the relevant material.
A separate recovery rehearsal needs specialist planning, as described above. Do not confuse a successful small task with proof that the whole website can be restored. Each check should state exactly what it demonstrated.
Use the results to repair the record. Replace vague folder names with exact locations, identify an out-of-date contact and distinguish a draft logo from the approved version. The aim is making the next person's job possible, not grading the previous provider.
Keep the record current when the arrangement changes
Review it when a provider, responsible person, platform or important service changes. Confirm the effect before cancelling an old service or removing access. Keep actual renewal information separate from assumptions about what happens automatically.
For a redesign, our guide to deciding what to retain from an old website covers the customer-facing content decisions. This handover record supplies a different piece: the control and recovery information behind those decisions.
If you are considering a new site or a change to an existing one, Time for Designs' website design information explains the starting point for an individually assessed project. Bring the record, including its unanswered questions. You do not need to pretend the gaps are already solved to have a useful discussion.
The website may look unchanged after you prepare this record. That is fine. Its value is that the business can explain what it depends on, who can act and which evidence supports the arrangement. A site that can be seen is useful. A site that authorised people can maintain and recover is a more dependable asset.
Sources and reading notes
ICANN's dated security guide supplies enduring account-control principles; the current transfer resource concerns its applicable policy scope. WordPress guidance is a system-specific example of complete backups. The evidence matrix and rehearsal sequence are Time for Designs' editorial guidance. No client accounts were inspected, no firsthand project result is claimed, and no transfer, recovery or account change was performed for this article.