Replacing your real estate website?
Check the launch plan.

The short answer.

A replacement website is ready when the important visitor journeys work, the old addresses have an agreed destination, and someone can recover the previous working state. A new design alone is not a launch decision.

Use this sequence with your designer, current provider and brokerage. It is a planning worksheet, not a promise that every platform, listing feed or customer record can be migrated. If you still need to establish who controls the accounts or what you can reuse, start with the ownership and handover checklist. This guide takes those answers into a launch sequence.

1. Decide what is actually changing

Write one sentence describing the replacement: for example, “Keep our domain and useful page addresses, replace the design, and send website enquiries to the existing approved destination.” This is an illustrative scope, not a completed client project.

Separate four decisions: design, content, website platform and domain. Changing the design does not automatically require a new domain or different page addresses. Ask the technical owner which changes are necessary and which can wait. Google’s site-move guidance recommends changing one thing at a time when possible; avoid bundling a domain move, platform change and redesign without a clear reason and plan.

Record what must remain available during the work: business email, contact information, key service pages, listing search where permitted, and the destination for enquiries. Agree a review owner and a technical launch owner. They may be different people.

2. Make a small but useful URL decision sheet

Start with your current page inventory, sitemap and available search or analytics reports. Include pages linked from advertising, email signatures, business profiles and printed QR codes. Low recent traffic does not by itself prove a page is disposable. Include useful downloadable files and images whose addresses are shared externally.

For each important address, complete:

Keep useful addresses where appropriate. If an address changes, have the technical owner plan a relevant destination and the appropriate permanent redirect. Google recommends avoiding irrelevant redirects and redirect chains: sending every old page to the homepage is not a substitute for a considered map. Do not delete pages merely to make the sheet shorter. Resolve removals and redirects as explicit project decisions.

For a same-domain redesign with unchanged URLs, there may be no URL move to perform. Still verify that those addresses render the correct content on the replacement site.

3. Resolve real-estate dependencies before selecting a launch date

List only the dependencies that apply to your site, then attach a decision and responsible contact to each:

• Listing search or IDX: ask the provider what must be approved for the new website, domain and brokerage arrangement. Do not assume the old feed or saved-search functions transfer automatically.
• Brokerage identity and content: identify who approves current brokerage details, disclosures, portraits, testimonials and reused photographs. Do not move material with unresolved rights.
• Enquiry destinations: confirm the expected recipient or CRM destination for each form, and who covers an unavailable agent. A visually correct form is not delivery evidence.
• Domain and email: ask the technical owner to identify which changes affect website traffic and which records keep business email working. Replacing a website does not necessarily require transferring its domain registration.
• Existing services: record renewal and cancellation dates. Keep required services active until the agreed acceptance checks are complete; avoid cancelling the old provider merely because the new design looks finished.

An unresolved dependency should name a person and a next action, not be hidden behind “ready soon.” These questions establish scope; they do not imply that specialist integration or migration work is included in a starting website price.

4. Review the replacement before cutover

Have the provider supply a controlled preview and agree who can access it. Keep private customer information out of review material. Ask the technical owner how preview indexing is restricted and how launch-only restrictions will be removed from pages intended for public search.

Review the actual pages, not just a homepage mockup. On desktop and a narrow mobile screen, follow a buyer path, a seller path and the contact path relevant to your business. Check navigation, readable text, real images, current contact details and any approved listing features. Open the important destinations from the URL decision sheet.

Arrange any delivery test with the responsible provider in advance. Use an agreed, labelled test method and confirm the destination without counting it as a genuine sales enquiry or triggering unsolicited follow-up. Do not enter another person’s details to test a form.

Ask for a recoverable before-state and a specific recovery owner. A backup file is not the same as evidence that the provider can restore the affected site. Agree what failure would stop the launch, what can be repaired after launch, and who decides.

5. Make the go/no-go decision explicit

Use this release card at the agreed launch review:

Record the approver, time and any accepted non-critical follow-up items. Do not treat this worksheet as authorization for your supplier to make unagreed domain, server, redirect or deletion changes.

6. Check the live result and then retire replaced services

Immediately after the agreed cutover, repeat the critical journeys on the public site. Check important old and new addresses, relevant redirects, internal links, canonical URLs and sitemap entries. Ask the technical owner to verify that intended public pages are not accidentally blocked by preview restrictions. Confirm business email continuity with its responsible owner using an agreed method.

Monitor errors and available Search Console information over the following weeks. Google notes that significant site changes can cause temporary ranking fluctuations while pages are recrawled and reindexed; there is no guaranteed recovery date or guaranteed preservation of rankings. Separate a broken link or failed enquiry path, which needs prompt repair, from short-term search movement that needs diagnosis.

Keep an issue log with the URL, observed problem, owner and resolution evidence. Close the replacement only when the agreed checks pass and the remaining responsibilities are accepted. Then cancel replaced services in the agreed order, preserving anything still required for email, redirects, records or recovery.

Bring these five answers to a replacement enquiry

1. What is your current website address, and why are you replacing it?
2. Which pages and visitor journeys must remain available?
3. Which domain, listing, email or CRM dependencies need provider confirmation?
4. Who approves content and who makes the launch decision?
5. What deadlines or cancellation dates constrain the sequence?

Keep passwords and transfer codes out of the brief. Share access through the relevant provider’s secure process only when it is needed.

HomePage.Studio assesses your current site, reusable content, provider limits and required work before agreeing replacement scope. See our real estate website service and website budget worksheet, or discuss your website.

Source

Google Search Central: moving a site with URL changes. Applies to actual URL changes; a visual redesign with unchanged URLs is not automatically a domain move. Source checked October 10, 2026. The release card and decision sheets above are original planning tools, not claims of a tested client migration.