Hotel SEO Migration Guide: Do Not Nuke Your Rankings During a Redesign

So you are finally redoing the hotel website. The one with the 2016 hero slider, the booking button that hides on mobile, and the spa page that loads like it is buffering a movie. Good. It is time.

But here is the part nobody at the design agency wants to lead with: a website redesign is the single most common way independent hotels accidentally delete their own Google rankings overnight. Not a penalty. Not an algorithm update. A self-inflicted wound, served up by a beautiful new site that quietly broke every URL Google had memorized about you.

I have watched a property go from page one for city plus boutique hotel to page four in a weekend, because the new site changed every URL and nobody set up redirects. The rooms were nicer. The photos were stunning. And the phone stopped ringing, because the organic traffic that used to feed direct bookings just evaporated into a pile of 404 pages.

This guide is the checklist I wish every hotelier ran before, during, and after a migration. It is detailed on purpose. Print it, hand it to your developer, and refuse to launch until every box is ticked.

First, what actually counts as a migration

People hear “migration” and think “moving servers.” It is broader than that. From Google’s point of view, a migration is any meaningful change to:

• URLs (you redesigned and the rooms page went from /our-rooms to /accommodation/rooms)
• Domain (you finally dropped the hyphenated nightmare and bought the clean .com)
• Protocol or host (moving to HTTPS, or from www to non-www)
• Site structure or platform (WordPress to a custom build, or onto a booking-engine-hosted CMS)
• Content and templates (you rewrote and reorganized everything, even if the domain stayed)

If your project touches any of those, you are doing a migration whether the proposal calls it that or not. The rankings do not care what the invoice says.

The pre-launch phase: build your safety net before you touch anything

This is the phase everyone skips because the new site is exciting and the old one is embarrassing. Do not skip it. Everything that saves you later gets created here.

1. Crawl the old site and freeze an inventory

Before a single pixel changes, run a full crawl of the current live site with a tool like Screaming Frog. You are creating a permanent snapshot. Export and save:

• Every URL that returns a 200 (your real, live pages)
• Page titles, meta descriptions, and H1s for each
• Status codes (find the existing redirects and 404s now, so you do not carry the rot forward)
• Internal links, so you know which pages link where
• Word count and any pages with unusually deep content (long guide pages, neighborhood pages, event pages)

Save this as a dated spreadsheet. This is your source of truth. If a page disappears from the new site, this file is how you prove it existed.

2. Pull your “money pages” from analytics and Search Console

A crawl tells you what exists. It does not tell you what matters. Open Google Analytics and Google Search Console and pull, for the last 12 months:

• Top 50 landing pages by organic traffic
• Top queries you actually rank for and get clicks from
• Pages with backlinks pointing at them (use your backlink tool of choice)

These are your money pages. Your homepage, your top room-type pages, your “things to do near” content, your offers page. Flag every one. If a money page changes URL, it gets a redirect with your name on it and a personal post-launch check. No exceptions. If you are unsure which content is even pulling weight, the hotel SEO starter guide walks through how to read these reports without a degree in analytics.

3. Build the URL map (this is the whole ballgame)

The URL map is a simple spreadsheet with two columns that decide whether your migration is a non-event or a catastrophe:

Every single old URL from your crawl needs a row. For each one, the new URL is either:

• The matching new page (most rows), or
• The closest relevant page if that content is being merged or retired (never send a retired room page to the homepage if a rooms-index page exists, send it there), or
• Genuinely nothing (rare) which becomes an intentional 410, decided on purpose, not by accident.

The cardinal sin here is the lazy redirect: pointing 200 dead URLs at the homepage because it is fast. Google reads a pile of redirects-to-homepage as “soft 404,” ignores them, and you lose the equity anyway. Map to the most relevant page or do not bother.

4. Don’t carry forward your old architecture mistakes (or invent new ones)

A migration is the rare moment you get to fix structure cleanly. If your current site buries room types four clicks deep, this is your chance. But fix it deliberately, mapped row by row, not by improvising during launch week. Our breakdown of hotel website architecture that ranks is worth a read before you finalize the new URL structure, because the structure you choose now is the one you will be redirecting to for years.

5. Stage it, and keep robots out

Build the new site on a staging URL or password-protected environment. Two things that must be true on staging and then flipped at launch:

• Staging is blocked from indexing (password protection is safer than relying on robots.txt and a noindex tag, both of which get forgotten)
• The day you launch, that block is removed. The classic horror story is launching a perfect site that ships with noindex still on every page because nobody flipped it. Google obediently removes you from the index. Put “remove staging noindex / robots block” at the top of your launch-day list in bold.

The launch phase: the day-of checklist

Pick a low-traffic window. For most independent hotels that is a weekday morning, not Friday afternoon and absolutely not the night before a holiday weekend when bookings spike.

Here is the launch-day sequence, in order:

1. Implement all 301 redirects from your URL map. Server-level (in the host config or via the platform’s redirect manager) is more reliable than a plugin, but a well-maintained plugin beats no redirects.
2. Remove the staging index block. Confirm the live site is crawlable.
3. Check the robots.txt on the live domain. Make sure it is not still the staging version blocking everything. One stray Disallow: / ruins your quarter.
4. Verify the XML sitemap generates from the new URLs and points only to live, indexable, 200-status pages. No redirected URLs, no 404s in the sitemap.
5. Confirm canonical tags point to the correct new URLs (self-referencing on each page), not back to old paths or staging.
6. Re-check the booking engine handoff. This is hotel-specific and constantly broken in migrations: the deep links from your room pages into the booking engine, the rate-code parameters, the date-picker links. If those break, you have a gorgeous site that cannot take a reservation. Test an actual booking, end to end.
7. Keep analytics and tracking firing. Confirm your GA4 tag, Search Console verification, and any call-tracking are present on the new templates. Migrations love to drop the tracking snippet and leave you blind for two weeks.

Test your redirects for real

Do not trust the spreadsheet. Test it. Take your old-site crawl export, feed that exact list of old URLs into a crawler in “list mode,” and crawl them against the live new site. What you want to see for every old URL:

• Status 301 (not 302, which is temporary and does not pass equity the same way, and not 200 meaning the old URL is somehow still live and now duplicating content)
• A single hop to the final destination (old URL goes straight to new URL, no chains)
• A final destination returning 200 (not a redirect that lands on a 404)

Redirect chains are the silent killer here. /old-page to /intermediate to /final bleeds equity and slows crawling. Collapse every chain so each old URL points directly at its final home in one hop.

Treat launch day like a pilot’s pre-flight checklist, not a vibe. The plane looking shiny on the runway tells you nothing about whether the fuel line is connected. Test the redirects, test a real booking, test the tracking. Then push it live.

The post-launch phase: the first 30 days decide everything

The site is live. The redirects test clean. You are not done. The post-launch window is where you catch the things that slipped through, and where Google decides how much of your old authority transfers.

Week one: submit and watch

• Submit the new XML sitemap in Google Search Console. If you changed domains, use the Change of Address tool in Search Console, it explicitly tells Google the move is intentional.
• Keep both old and new properties verified in Search Console if the domain changed, so you can watch the handoff from both sides.
• Monitor the Coverage / Pages report daily for a spike in 404s, “Excluded by noindex,” or “Blocked by robots.txt.” Each of those is a specific, fixable mistake, not bad luck.

Weeks two to four: hunt the leaks

Expect a short ranking wobble. A two to six week dip while Google recrawls and reprocesses is normal and not a reason to panic-revert. What you are watching for is the difference between a normal wobble and a real leak:

• Crawl the new site fresh and compare the page count and titles against your frozen old-site inventory. Pages missing? Titles gone generic? Fix them.
• Find orphan pages that exist but nothing links to. The new navigation often forgets a page the old menu included.
• Watch internal links. Redesigns frequently strip internal links that were quietly doing SEO work, like the contextual links between your neighborhood guide and your room pages.
• Re-check page speed on the new templates. New sites love to ship with giant unoptimized hero images and five tracking scripts. If the new build is slower than the old one, you traded rankings and conversions for looks. Our piece on hotel page speed and direct bookings covers what to actually measure.

The branded-search canary

One fast, hotel-specific health check: search your own hotel name. You should rank first for it. If a migration went sideways, your own brand term is often the first place you see slippage, and the OTAs are right there waiting to soak up the clicks you dropped. We get into why this happens in why your hotel ranks below the OTAs for your name. Keeping a tight grip on your branded search is one of the most direct ways to win back direct bookings and reduce how much margin the OTAs quietly skim through commissions that run roughly 15 to 25 percent per reservation. A clean migration protects that. A sloppy one hands it away.

The short version, pinned to your monitor

If you only remember five things:

1. Crawl and freeze the old site first. You cannot map what you did not record.
2. Build a complete, one-to-one URL map. Every old URL gets a destination, mapped to relevance, never lazily to the homepage.
3. Implement clean 301s, single-hop, tested against the live site with your old URL list.
4. Flip the index block off and the sitemap on at launch, and confirm robots.txt is not strangling the new site.
5. Watch Search Console daily for 30 days and treat every 404 spike as a bug to squash, not weather to wait out.

A migration is not where you lose your rankings. A migration without this checklist is. The hotels that come out the other side stronger are the ones that treated the redesign as an SEO project that happens to involve a designer, not a design project that happens to involve a website.

Planning a redesign and want a second set of eyes before launch day turns into a 404 graveyard? Our hotel SEO service includes full pre-launch migration audits, URL mapping, and redirect QA, the unglamorous work that keeps your direct-booking traffic alive through the move. See what that costs, or just book a call and bring your URL map.