A new real estate website is almost always presented as a single moment: the day it goes live. Agencies take progress photos, agents share the link in an email, and the assumption is that the work is now mostly done.
The first six months of traffic say something different. A relaunch that drops below the old site's traffic and stays there is usually not a design problem or a content problem. It is a launch problem: a decision made (or skipped) in the week around the cutover that cost the site its earned ranking, or kept Google from finding it at all.
The question worth asking goes past how the new site should look. It is about when the site should go live, what should be in place before it does, and what the first two weeks look like when the launch is done right.
What actually happens the day a new site goes live
A real estate website has usually been indexed by Google and Bing for months or years. Those indexes hold a map: here is the page about buying a condo in your area, here is the neighbourhood guide, here is the agent bio, and here is where each one ranks for the queries people type.
When a new site replaces the old one, that map has to transfer. Three things decide whether it does:
- Redirects. Every URL on the old site needs a 301 redirect pointing to the matching page on the new site. A 301 tells search engines the page has permanently moved, and most of the earned ranking transfers with it. Without the redirect, the old URL returns a 404 the moment the switch happens, and Google eventually drops it from the index along with the ranking.
- Sitemap and indexing requests. Google's documentation on submitting a sitemap describes this as the supported way to tell Google which pages on a site matter, and submitting a fresh sitemap through Search Console on launch day is the fastest way to signal "there is a new structure here, please crawl it." For individual pages that need to be found quickly, Google's own recrawl request documentation covers using URL Inspection to request indexing.
- The DNS cutover itself. Only one version of the site should answer after launch. If the old version is still reachable at a secondary subdomain, or if www and non-www both resolve to different content, search signals split across the versions and nothing ranks as well as it should.
None of this is visible to someone looking at the home page. All of it decides whether the home page gets visited.
A pre-launch checklist that actually matters
The checklist here is deliberately short. Everything else is design and content work that stops mattering if these items are not in place first.
One, a full URL inventory from the old site. Export every indexed URL from Search Console's Pages report, add a Screaming Frog or similar crawl of the live site to catch anything the index missed, and build a spreadsheet with one row per old URL.
Two, a redirect map. In the same spreadsheet, add a column for the new URL each old URL should redirect to. Most pages have a clear one-to-one match. Pages that no longer exist (an old agent's bio, a retired service page) should point to the closest relevant replacement, not the home page. Multiple old pages that all covered the same topic should consolidate into a single new page.
Three, the sitemap. The new site should generate an XML sitemap at build time, located at a predictable URL like /sitemap.xml. It should list every page that should be indexed and exclude pages that should not (thank you pages, preview pages, admin pages).
Four, a Core Web Vitals check before launch. Load the staging site in PageSpeed Insights and confirm the main pages pass the three Core Web Vitals metrics on mobile. Google's Core Web Vitals report documentation describes how these metrics get used as a ranking signal. A new site that launches with slow mobile loading gives Google a reason to rank it below the old version.
Five, a form test from an external device. The contact form has to send an email to the real inbox the agent actually checks, not a test inbox nobody reads. This gets missed on roughly every second launch.
When to publish, in real estate
Most relaunches should avoid the peak listing weeks in the local market, because that is the window where a ranking dip or a broken form costs the most. In most Canadian and US markets the peak sits from mid-April to mid-May, with a secondary peak in September. Launching into that window is not fatal, but it leaves less margin if something needs to be fixed.
The lower-risk windows are the last two weeks of January through early March, and the second half of October through late November. Buyer and seller search traffic is lower, feedback loops are quicker, and there is time to work through the first two weeks of fixes before the next cycle of listing activity picks up.
That is a general pattern, not a rule. A well-prepared launch in early May can go cleanly. A rushed launch in February can go poorly. The timing is one input into the risk calculation, not the whole calculation.
The first week, done right
Day one of a well-run launch looks less like a celebration and more like a checklist being worked through by whoever is responsible for the site.
The DNS cutover. The new site is already deployed and responding on a staging URL. Flipping the production domain to point at the new host takes a few minutes and propagates over an hour or two. The final URLs should be verified on an outside network, like a phone on cellular data, because DNS caches differ between networks and the office wifi can show a stale answer for an hour or more.
Redirects verified against the old URL list. The spreadsheet from the pre-launch checklist becomes a checklist of 301 responses. A sample of twenty or thirty old URLs should be checked by hand, including any pages that previously ranked for competitive search terms.
Search Console and Bing Webmaster Tools. The new sitemap gets submitted in both tools on day one. The URL Inspection tool in Search Console is used to request indexing on the home page, the main service page, the top two or three neighbourhood pages, and the agent bio. Bing's IndexNow protocol can be set up at the same time to speed indexing on Bing and Yandex.
Analytics and conversion tracking. The analytics code needs to be live before traffic arrives, not added the following week. For a real estate site, the contact form submission, phone click, and any lead magnet download should each fire a defined event so the launch's actual conversion rate can be measured from day one.
Day two through four is monitoring. Search Console starts surfacing crawl errors, 404s, and redirect chains within twenty four to forty eight hours of the launch. Every error in that first week is a chance to fix something before it becomes the reason a page stops ranking.
When the first two weeks go wrong
Three patterns show up often enough to name.
Traffic drops hard and does not recover. Almost always a redirect problem. The old URLs are returning 404 instead of 301, and Google is slowly dropping the old pages from its index. The fix is to put the correct redirects in place and resubmit the sitemap, and recovery usually begins within a few weeks, though it can take longer on a site that had a lot of ranked pages.
Traffic dips briefly then returns. Normal. Google reprocesses the new URL structure over a couple of weeks and rankings usually settle back near their previous level, with the new site's genuine improvements showing up a month or two later.
Traffic is flat but nobody can find specific pages. Often a sitemap problem. The new pages exist on the site but are not listed in the sitemap, so Google is finding them slowly through internal links instead of all at once. The fix is to regenerate the sitemap, confirm the missing pages are in it, and resubmit.
The pattern in all three is the same. The launch problem is usually not what was built. It is a connection between the old site and the new site that did not get made.
The takeaway
The build is the visible part of a new real estate website, and it is usually the better part by the time launch arrives. What decides whether the launch pays off in the next six months sits around the switch itself: the full URL inventory, the 301 redirect map, the sitemap submitted on day one, the URL Inspection requests on the home page and the pages that matter, and a careful two weeks of watching Search Console for anything that needs a fix.
Planning the launch this way is the difference between a relaunch that recovers its old traffic in month one and starts growing in month three, and a relaunch that is still waiting to be found in month six.
If the site is still in the planning stage, a free rebuild preview can show how the new URL structure and the redirect map would look before any work starts. The website checklist post covers the content side of the same question, and the contact page is a good place to start if you have a launch coming up and want a second set of eyes on it.
