Keep website access when someone else builds it

Keep the business in control of its domain, important accounts and published content when someone else builds the website. Agree who owns each asset, who manages it and how access will be handed over. Test that arrangement before the project ends.

Ownership and everyday management are different. A builder may need permission to update the site without becoming the only person who can recover its accounts. An owner may not want to handle technical settings but should still know where the accounts are and how an authorized replacement would obtain access.

Start with an asset inventory

List the domain registration, DNS management, hosting, website editor, source files, media library and form delivery service. Include any business profile or third-party account involved in the project. Record the account holder, responsible person and recovery method without putting passwords in the document.

Some services combine several of these functions. Others separate them. The inventory should reflect your actual setup rather than a diagram copied from another business. Ask the builder to explain any item you cannot identify.

Add the renewal responsibility for paid services. A working website can be disrupted because an important renewal notice goes to a former employee or an unmonitored mailbox. Knowing who pays and who receives notices is part of maintaining access.

Use business-controlled recovery details

Important accounts should use contact and recovery arrangements the business can maintain. Avoid making the long-term setup depend entirely on a contractor's personal email or a departing employee's device.

Use the provider's supported permission system where available. Give the builder the access needed for the task rather than sharing a single password among everyone involved. The owner should understand who has permission and how that permission can be changed.

Store credentials in an appropriate secure system. Do not place them in a project brief, email thread or public repository. A handover document can identify the account and explain the access process without containing the secret itself.

Agree what the project delivers

A finished website can mean different things to different people. Clarify whether the delivery includes editable content, source files, original media, design files and instructions for routine changes. Identify any third-party components with separate licenses or subscriptions.

Ask how the site can be moved if the hosting arrangement ends. Some systems can be transferred directly; others require an export or a rebuild. Understand that distinction before relying on a future move as an easy option.

Our website design service begins with project scope. A useful scope describes the intended pages and functions alongside the practical responsibilities that keep the finished site usable. The handover should match those agreed deliverables.

Protect the information customers already rely on

If an existing site is being replaced, inventory its useful pages and customer instructions before work begins. Save the current content and note which URLs people may already have bookmarked or received by email.

The builder needs to know which information must remain accessible. A redesign should not accidentally remove the only explanation of service coverage, preparation or visiting arrangements. Review the core offer using the service-page-first approach.

Keep business facts separate from presentation choices. A new layout can change where information appears, but the owner should approve changes to scope, prices or promises. Design approval alone should not be treated as approval of rewritten service terms.

Include forms and email in the handover

A site can look complete while its inquiries are being sent to an account only the builder can access. Document where form submissions go, who receives notifications and what confirmation the visitor sees.

Run an authorized test and check the actual receiving inbox. If the system stores a backup of submissions, identify where it is and who can view it. Do not assume the on-screen success message proves the delivery chain works.

The form should also remain understandable to customers after the builder leaves. The checklist in giving inquiry forms enough context covers field purpose, errors and next steps. Save the approved wording with the project records so future edits preserve its meaning.

Test access with the person who will use it

Have the owner or designated staff member sign in through the intended account. They should be able to perform the routine tasks assigned to them, such as editing a service description or replacing a photo, without borrowing the builder's credentials.

Check recovery and support arrangements before there is an emergency. Record the provider's official support route and the account details needed to identify the service. Keep the builder's role clear if they will provide ongoing maintenance.

Use a safe practice change where possible. Editing a draft or replacing a test image can reveal missing permissions without affecting customers. A successful login alone does not establish that the person can complete the tasks they will actually need to do.

Make the handover a usable document

Keep the document short enough to consult. It should identify the systems, responsibilities, renewal dates, routine editing steps and escalation route. Link to provider documentation where that is more reliable than copying a long set of instructions.

Ask the builder to note any known limitations. A feature that requires technical help should be identified as such. Do not leave staff assuming that every visible part of the site can be changed safely in the same editor.

Review access when people or suppliers change. Remove permissions through the provider's normal process when they are no longer needed, while preserving business-controlled ownership and recovery.

Resolve uncertainty before the project closes

A good handover leaves the business able to explain who controls the domain, where the site runs and where inquiries arrive. It also leaves the builder with a clear boundary around any ongoing responsibilities.

If you are preparing a new site or trying to understand an existing arrangement, request a search review with the website address and the access question you want to resolve. Describe the uncertainty without sending passwords, private recovery codes or account tokens.