If you’re rebuilding your website, you may wonder whether to take the old one down while you work. Don’t. A site that disappears, or shows a “coming soon” page for weeks or months, costs you customers, leads and search visibility you worked hard to earn.
Table of Contents
This guide covers why the old site should stay up, where to build the new one, how to keep it out of Google, and how to switch over with redirects, so your traffic and rankings survive the launch.
Quick Answer
Yes. Keep your old website live and fully working while you build the new one on a separate, private staging site or a temporary URL. When the new site is ready, swap it in and set up 301 redirects from every old URL to its closest new equivalent. Only take the old site down after the switch, and keep a backup of it.
Why You Should Keep the Old Site Live
Your current site is probably still doing work: ranking in search, collecting leads, answering customer questions, and holding backlinks from other sites. Taking it offline, or replacing it with a placeholder, stops all of that and signals to search engines that your pages are gone. Recovering rankings afterwards can be slow and is never guaranteed.
Building in the open is also risky. A half-finished site can confuse visitors and give a poor first impression. Working privately lets you take the time to get the design, content and structure right before anyone sees it.
Step-by-Step: Build the New Site Without Disrupting the Old One
Step 1: Inventory the old site. Before you touch anything, crawl or export a list of every URL, and note which pages get traffic, bring in leads or have links pointing to them. You can pull this from Google Search Console, your analytics and a crawler such as Screaming Frog. This list becomes your redirect map later.
Step 2: Build on staging. Use a staging environment or a temporary subdomain such as new.yourdomain.com, or a separate development URL from your host or website builder. Many managed WordPress hosts offer one-click staging. Your old site keeps running on the main domain the whole time.
Step 3: Keep the staging site out of Google. Put it behind password protection (HTTP authentication) or an IP restriction, since that is the most reliable option. Add a noindex tag as a backup. Don’t rely on robots.txt alone: a robots.txt block stops crawling but can still leave a URL indexed if other sites link to it, and it also stops Google from ever seeing a noindex tag on the page. If the staging site is public and indexed, it can compete with your real site through duplicate content.
Step 4: Recreate what matters. Carry over the pages that rank and convert, and keep their titles, headings and content quality at least as strong. Google notes that if you redesign content and URL structure at the same time as a move, you should expect some traffic fluctuation while it reassesses your pages, so change only what you need to. Where you can, keep the same URLs.
Step 5: Freeze changes and test. Once the new site is nearly done, pause major edits on the old one (or keep a log so you can copy them over). Then test forms, checkout, tracking codes, mobile layout, page speed and every redirect on staging.
Launch Day: Switching Over Safely
Remove the password protection and every noindex tag from the new site. Forgetting these is one of the most common launch mistakes, and it can quietly remove your pages from search. Google advises keeping a list of the URLs where you added noindex rules so you can undo them at launch.
Then point the domain at the new site (or copy it to the live server) and turn on your 301 redirects. Send each old URL to its closest equivalent page, not just the homepage, and avoid chains where one redirect leads to another. Submit your new sitemap in Google Search Console and check the Pages and crawl-error reports over the following days.
Keep the redirects in place for as long as possible. Google’s guidance is generally at least a year. Also keep a full backup of the old site, files and database, in case you need to restore or refer back to something.
Tips / Common Mistakes
Don’t put up a “under construction” page over your live site. Build elsewhere and swap when ready. Don’t launch on a Friday afternoon, because you want time to catch problems while you’re available to fix them. Don’t redirect everything to the homepage; that is treated as a poor match and frustrates visitors. Don’t forget email, DNS and SSL: if you’re changing hosts, check that your email records and HTTPS certificate carry across.
If you’re moving to a new domain as well, that’s a bigger job. Use Search Console’s Change of Address tool once redirects are working, and expect to monitor closely for weeks. If your budget or timeline is tight, get help from a developer who has done migrations before; a mistake here is far more expensive than the fee.
Explore more: More web development guides for small businesses.
Keeping your old website live during a rebuild FAQs
Can I take my old website down while I build the new one?
You can, but it’s rarely a good idea. Taking the site offline stops leads and search traffic, and search engines may drop your pages. Build the new site on a private staging URL and keep the old one live until the switch.
Will a staging site hurt my SEO?
Only if it gets indexed. A public staging copy can create duplicate content and compete with your live site. Protect it with a password or IP restriction and add noindex as a backup, then remove both at launch.
How long should I keep 301 redirects after launching a new site?
As long as possible. Google generally recommends at least one year so it can transfer signals to the new URLs, and keeping them longer helps visitors with old bookmarks and links.
Do I need to keep the old site online after the new one launches?
Not on the same address, since the new site replaces it. But keep a complete backup, and keep redirects from the old URLs pointing to the new pages.
Build It With GTStudios
Need help with your website, app, or small-business tech? GTStudios builds web, apps, and software for small businesses. See how GTStudios can help.
Want dev news in your inbox? Subscribe to the free newsletter.
Photo by Kari Shea on Unsplash.