The Complete Guide
Rebuilding a Real Estate Website Without Losing What Works
How to tell whether your site needs a rebuild, what actually breaks when you move it, and how to judge the result.
A real estate website rebuild replaces the design, structure, and code of an existing agent or brokerage site while keeping the addresses that search engines already trust. The risk is not the design work. It is the move: when page addresses change and nothing tells Google where they went, the rankings those pages earned are lost. Google's own guidance is that permanent redirects are what carry ranking signals from an old address to a new one, and that a small to medium site takes a few weeks for most pages to settle. A rebuild done in that order keeps the traffic and changes everything else.
Key takeaways
- The decision is rarely about how the site looks. It is about whether the pages can be read, found, and acted on.
- Google states that permanent redirects (301 and 308) pass canonical signals to the new address, while temporary redirects (302, 303, 307) do not.
- Google recommends keeping redirects in place for at least a year, and suggests keeping them indefinitely for the sake of visitors with old bookmarks.
- Content that only appears after JavaScript runs is invisible during Google's crawling phase and waits in a rendering queue, which Google says can take longer than a few seconds.
- Core Web Vitals are used by Google's ranking systems, but Google says good scores alone do not guarantee a top position.
- NAR's 2025 survey found 88% of buyers purchased through an agent and 91% of sellers sold with one, so the website's job is to win the introduction, not to replace the agent.
The question is not whether the site looks dated
Most agents decide to rebuild because the site looks old next to a competitor's. That is a reasonable trigger, but it is a poor test, because appearance is the one problem a rebuild always fixes and rarely the one costing money. A site can look perfectly modern and still be unreadable to a search crawler, slow on a phone, or missing the pages a buyer actually searches for.
A better test has three parts, and they run in order. Can the pages be read by an automated visitor? Can a person find the answer they came for within a few seconds? Is there anything on the page that lets them start a conversation? A site that fails the first question cannot be fixed by better writing, because nothing is reading the writing. A site that passes all three does not need a rebuild, it needs new pages.
This ordering matters because it decides how much work you are actually buying. Rebuilds get sold as design projects and then quietly become migrations, which is where the money and the rankings go.
What a rebuild puts at risk, in plain terms
Every page on your current site has an address. Some of those addresses have been collecting value for years: Google has indexed them, other sites link to them, past clients have bookmarked them. That accumulated value is attached to the address, not to the words on the page.
A rebuild that changes addresses without redirecting them throws that away. Google's documentation on site moves is direct about the mechanism: it recommends permanent redirects, specifically 301 and 308, and explains that the indexing pipeline treats a permanent redirect as a signal that the new address should become the canonical one. Temporary redirects, meaning 302, 303, and 307, are followed but are not used as that signal. The difference is one number in a server configuration file, and it decides whether ten years of ranking history transfers or disappears.
- Page addresses change and nothing points the old ones at the new ones, so the ranking history is stranded.
- The wrong redirect type is used, so Google follows it but does not treat the new address as the replacement.
- Internal links still point at old addresses, which Google's site-move guidance says to update to the new addresses.
- The new site's content loads through JavaScript, so the crawling phase sees an almost empty page.
- The old sitemap is left in place, so search engines keep being told about addresses that no longer exist.
- Pages nobody thought were important, such as an old neighbourhood guide, are dropped without checking what they were ranking for.
How search engines actually see a rebuilt page
Google describes its processing in three phases: crawling, rendering, and indexing. During crawling it fetches the address and reads the HTML the server sends back. Rendering, where JavaScript runs in a headless browser, happens afterwards and from a queue. Google's own wording is that a page "may stay on this queue for a few seconds, but it can take longer than that."
For a real estate site this is not a technicality. Listing feeds, neighbourhood pages, and sometimes the agent's own biography are commonly delivered by an embedded widget that only fills in once JavaScript runs. In the crawling phase, those pages are close to empty. Google still recommends server-side or pre-rendering, and says so plainly: it "makes your website faster for users and crawlers, and not all bots can run JavaScript."
That last clause is the part worth holding on to. Google's renderer is comparatively capable. The retrieval passes behind AI assistants are generally less so. A page built to be readable without JavaScript is doing one piece of work that pays in both places.
Speed matters, but not in the way it is usually sold
Core Web Vitals are Google's three measurements of page experience: Largest Contentful Paint for loading, at 2.5 seconds or less; Interaction to Next Paint for responsiveness, at 200 milliseconds or less; and Cumulative Layout Shift for visual stability, at 0.1 or less. Each is judged at the 75th percentile of page loads, split between mobile and desktop, so a site is measured by its slower visits rather than its best ones.
Google confirms these are used by its ranking systems. It also says, in the same guidance, that good scores "doesn't guarantee that your pages will rank at the top of Google Search results." And it states there is no single page experience signal at all. Anyone selling a rebuild on the promise that a perfect performance score produces rankings is overstating what Google has said.
The honest case for speed is simpler and does not depend on ranking at all. A visitor deciding whether to trust an agent with the largest transaction of their life forms an impression while the page is still loading. That is worth fixing regardless of what it does for position.
What the rebuilt site has to do for the business
It helps to be precise about the website's job, because a rebuild scoped around the wrong job produces a beautiful site that changes nothing. NAR's 2025 Profile of Home Buyers and Sellers, an annual survey based on 6,103 responses from people who completed a transaction between July 2024 and June 2025, found that 88% of buyers purchased their home through an agent or broker and 91% of sellers sold with one.
So the website is not competing with agents for the transaction. It is competing for the introduction. The same survey reports what buyers wanted help with: 50% cited finding the right home and 13% negotiating the terms of the sale, with 12% naming price negotiations and 7% paperwork. Those are the questions the site should visibly answer, because they are the ones on the reader's mind when they arrive.
That reframes the content brief. A page explaining how you price a home competitively speaks to a named seller concern. A page of stock photography and a tagline about trust speaks to nothing.
The order to do it in
Sequence prevents most rebuild disasters, because the expensive mistakes are all made before launch day and discovered weeks after.
- Inventory the current site first. Export every address Google has indexed, and note which ones bring in search traffic today. You cannot protect pages you have not listed.
- Decide the new structure before any design work, then map every old address to exactly one new address. Anything with no destination is a decision you are making, so make it deliberately.
- Build the pages so the content is in the HTML the server returns, not assembled afterwards by script.
- Put the redirects in as permanent ones, and test them against the real list before the old site goes away.
- Update internal links to point at the new addresses directly, rather than relying on the redirects to do it.
- Submit the new sitemap in Search Console, and if the domain is changing, use the Change of Address tool.
- Watch indexing for several weeks. Google says a small to medium site takes a few weeks for most pages to move, and that visibility may fluctuate during a move before settling.
When not to rebuild
Rebuilding is not always the right answer, and a vendor who never says so is not being straight with you. Three situations argue for editing what you have instead.
If the site already renders its content as text, loads quickly, and simply has too few pages, then the problem is content and a rebuild will not create any. If a rebuild is being considered purely because of a traffic drop, find the cause first, because a move made on top of an unexplained decline makes the two impossible to separate afterwards. And if the current site is the only thing ranking for your name in a competitive area, the safest change is incremental, not wholesale.
The case for a rebuild is strongest when the failures are structural: content that only exists after JavaScript runs, a platform you cannot add pages to, or a template shared with hundreds of other agents that offers nothing specific to your market.
| Redirect | Type | Effect on ranking signals |
|---|---|---|
| 301, 308 | Permanent | Googlebot follows it and treats the target as the canonical address |
| 302, 303, 307 | Temporary | Googlebot follows it but does not treat the target as canonical |
| Instant meta refresh | Interpreted as permanent | Treated as a permanent redirect by Google Search |
| JavaScript redirect | Last resort | Google says to use it only when server-side or meta refresh is impossible |
From Google Search Central's redirect documentation, linked below. Google recommends server-side permanent redirects where possible, and warns a JavaScript redirect may never be seen if rendering fails.
| Metric | What it measures | Good score |
|---|---|---|
| Largest Contentful Paint | How long until the main content appears | 2.5 seconds or less |
| Interaction to Next Paint | How quickly the page responds to a tap or click | 200 milliseconds or less |
| Cumulative Layout Shift | How much the layout jumps while loading | 0.1 or less |
Thresholds from web.dev's Core Web Vitals documentation, measured at the 75th percentile of page loads across mobile and desktop. Interaction to Next Paint became a stable Core Web Vital in 2024, replacing First Input Delay.
Frequently asked questions
Will rebuilding my website hurt my Google rankings?
It can, and the deciding factor is whether page addresses change and whether permanent redirects are put in place for the ones that do. Google's site move guidance recommends permanent redirects, specifically 301 and 308, and says the indexing pipeline uses them as a signal that the new address should be canonical. A rebuild that keeps addresses or redirects them permanently is far lower risk than one that quietly drops them.
How long do rankings take to settle after a website move?
Google says a small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer. It also states that visibility may fluctuate temporarily during a move and that rankings settle down over time. Nobody can give you a precise date, so plan to monitor indexing for several weeks rather than judging the outcome in the first few days.
How long should I keep the old redirects?
Google's guidance is to keep them for as long as possible, generally at least one year, because that lets Google transfer all signals to the new addresses including recrawling and reassigning links from other sites. It also suggests considering keeping them indefinitely, since visitors still arrive from old bookmarks and links long after search engines have caught up.
Do I need a new website, or just new pages?
Check whether your existing content is readable without JavaScript and whether you can add pages freely. If both are true, you likely need content rather than a rebuild, because a new site does not create pages you have not written. If your content only appears after scripts run, or the platform will not let you publish new pages, that is structural and editing will not fix it.
Does a faster website rank higher?
Speed contributes, but not as directly as it is usually sold. Google confirms Core Web Vitals are used by its ranking systems, while also stating that good scores do not guarantee top rankings and that there is no single page experience signal. Treat speed as something that helps visitors decide to stay, with any ranking benefit as a secondary effect.
What happens to my blog posts and neighbourhood pages in a rebuild?
They need to be inventoried before anything is designed, because these are often the pages bringing in search traffic even when nobody on the team thinks about them. Export the full list of indexed addresses, check which ones receive search impressions, and give each one a destination on the new site. Pages you decide not to carry over should be a deliberate choice, not an oversight discovered later.
Can I rebuild my site in sections instead of all at once?
Google addresses this directly and the answer depends on size. For smaller sites it recommends moving all URLs simultaneously, because that helps its systems detect the move and update the index faster. For larger sites it says you may move one section at a time, which makes problems easier to monitor, detect, and fix. Most single-agent sites fall into the first category.
Do I need to tell Google about the move?
Submit the new sitemap in Search Console so Google learns about the new addresses. If you are moving to a different domain, also submit a Change of Address for the old site. Google notes that a move from HTTP to HTTPS on the same domain does not require the Change of Address tool, though the redirects still apply.
Should the rebuilt site be readable without JavaScript?
Yes, and Google recommends it. Its JavaScript SEO guidance says server-side or pre-rendering is still a great idea because it makes the site faster for users and crawlers, and because not all bots can run JavaScript. Google's own rendering also happens from a queue that it says can take longer than a few seconds, so content in the initial HTML is simply seen sooner and more reliably.
Is a real estate website still worth investing in when buyers use portals?
The website's job is winning the introduction rather than hosting the search. NAR's 2025 survey found 88% of buyers purchased through an agent or broker and 91% of sellers sold with one, so the transaction still runs through a person. The site is where someone decides whether that person should be you, which is why pages answering real questions outperform pages describing the agent in general terms.
Related reading from the blog
Sources
Every claim on this page that could be checked against a primary source is linked below. Where something is not publicly documented by a vendor, the page says so rather than filling the gap with an estimate.
- Redirects and Google Search (Google Search Central)
- Site move with URL changes (Google Search Central)
- JavaScript SEO basics (Google Search Central)
- Understanding page experience in Google Search results (Google Search Central)
- Web Vitals (web.dev (Google))
- 2025 Profile of Home Buyers and Sellers (National Association of Realtors)
Want to know how your own site scores?
Every check on this page applies to a real website. Paste in your current site and Saige rebuilds it with readable text, stated facts, and structured data already in place, so you can see the difference rather than reading about it.
See how the rebuild works