Taking over an unfinished website: what to check first

A site described as almost finished may have a complete homepage and an enquiry form that reaches nobody. Another may look unfinished while its content system and integrations already work. A percentage hides those differences.

Write the journey your business needs in plain words: a visitor finds the right service, understands the offer, sends an enquiry and receives the expected confirmation. Add the editing task your team needs to perform after launch. Then inspect each step on the existing build.

Record the review URL, expected behaviour and observed result. Keep a failure you have reproduced separate from a function nobody has checked. That distinction gives the next supplier a more useful brief.

List who controls each account and who can authorise a review or handover. An invoice, a login and permission to reuse a design answer different questions. Ask the relevant owner or adviser to resolve an unclear permission before the work depends on it.

For a WordPress site, an Editor and an Administrator have different capabilities. A reviewer who can edit a page may still be unable to inspect settings or plugins. Agree the access needed for the specific review, using the platform's documented roles.

Create a short register with a page or function, its current state, the evidence and the person who decides whether it is acceptable. This gives a new supplier something to investigate without assuming every existing decision should be replaced.

A takeover does not automatically require a new identity, a new platform or a complete redesign. Ask the reviewer to explain which existing parts can be retained and which dependencies make further work uncertain.

Ask what you will be able to inspect at each review. A dated milestone should name the work, dependencies, reviewer and evidence needed for approval. Keep unresolved access, content and integration questions visible in the proposal.

Include important visitor and editor journeys in the checks. For accessibility, agree knowledgeable human evaluation alongside relevant tools. W3C explains that an automated tool alone cannot determine whether a site meets accessibility standards; a score is not a substitute for a defined evaluation scope.

If the takeover changes page addresses, record the existing URLs and their intended destinations before launch. Google's site move guidance covers preparing the new site, mapping URLs, applying redirects and monitoring the move.

Ask who checks changed addresses, internal links, canonical URLs, the sitemap and crawl access. Agree who reviews search and enquiry data after release. Preserving useful content and planning redirects belongs in the scope; a guaranteed search position does not.

Record the client's country and time zone, required languages, content approvers, hosting expectations and support contacts. Agree review windows and who can approve the release. Assign translation, specialist testing and regulated content review where the brief needs them.

At handover, inspect the agreed account access, source or exports, editing instructions and support record. Name the next renewal or maintenance owner for each continuing service. A link to a live site is one part of that record.

Start with the current URL, the original purpose of the site, the work you can demonstrate and the decisions that remain open. Add the account inventory, missing items, desired launch date and the person who approves the work. Redact confidential details.

Branding Tatva can review the brief before confirming feasibility and the next scope. Suman Sharma leads strategy, website messaging and client coordination. Development, specialist work, responsibilities, commercial terms and delivery dates are confirmed in the written proposal.