For about nine years, the Hotel Harmony website in Ghent did not change. It had been built in WordPress by an agency, and nobody on the reception team could be asked to learn WordPress. When it was finally rebuilt, the result showed up in the analytics within weeks. Often the hardest part of a hotel website migration is deciding to start.
The fear behind that delay is reasonable. Your current site may be dated, but Google knows it. It ranks for your hotel's name, your street and your city, and a new site that throws that away would cost you direct bookings for months.
It doesn't have to. Google publishes its own guide to moving a site, and for a hotel-sized website it comes down to six steps. By the end of this guide you will know what to export, what to map, what to redirect, what to test, and what to watch for the year after launch.
What you need before you start
- Access to Google Search Console for your current site. If nobody has it, verify the site now; the steps below depend on it.
- Login details for your domain registrar. You need to know who controls your domain name, separately from who built your site.
- A list of every place your booking engine is linked from, including your Google Business Profile, social profiles and any ads.
- Access to your analytics, so you can compare traffic before and after.
- A quiet week in your own calendar. Google advises timing a move for a period of lower traffic, so pick your low season, not your busiest month.
Step 1: Export every URL your current site has
Start with a complete list of the old site's addresses, because every one of them is either ranking for something or linked from somewhere.
Google suggests four places to look: your sitemap, the pages that get the most traffic in your analytics, the links report in Search Console, and the list of pages your content management system can export. Hotels need two more:
- Every language version. A room page in English, Dutch and French is three URLs, not one. A hotel with ten room pages in three languages has thirty room URLs to map before it has counted the homepage.
- Images and PDFs. The restaurant menu, the wedding brochure and the room photos may be getting traffic of their own. Google's guide says these need to move like any other page.
If a URL isn't on the list, it won't be redirected, and whatever it earned in Google goes with it.
Step 2: Map each old URL to one new URL
Put the list in a spreadsheet and give every old address one destination on the new site. Google's rule is one-to-one: the old Deluxe Double page goes to the new Deluxe Double page, not to the homepage.
| Old URL | New URL | Why |
|---|---|---|
/rooms/deluxe-double | /en/rooms/deluxe-double-room | Same room, new address |
/nl/kamers/deluxe-dubbel | /nl/kamers/deluxe-dubbele-kamer | Each language maps to its own language |
/menu-2023.pdf | /en/restaurant | The content moved into a page |
/news/christmas-2022 | Returns a 404 or 410 | Old content you are not keeping |
Sending many old URLs to the homepage is the most common shortcut and the one Google warns against by name: it can confuse travellers, and Google may treat it as a "soft 404", a page that exists but doesn't answer what was asked. Pages you are deliberately dropping should return a 404 or 410 error instead.
One old page, one new page, in the same language. Anything else is a guess Google has to make for you.
Step 3: Keep your domain, and change one thing at a time
If you can, keep the address travellers already know. Google's guide advises changing one thing at a time: if you want a new domain, a new content management system and a new design, do them one after the other, not together.
Replacing your website provider already changes two of those. Keeping yourhotel.be means the move is a change of pages within one domain, which is the simpler case. You will not need Search Console's Change of Address tool, which Google says is only for moves from one domain or subdomain to another.
If you do change domain, submit a Change of Address request for every verified variant of the old domain, and keep paying for the old domain. Search Console's help page recommends renewing it for at least a year so nobody else can buy it and use it.
Step 4: Set up permanent redirects, then fix the tags behind them
Each line of your mapping becomes a redirect. Ask whoever hosts the new site for server-side permanent redirects, 301 or 308, which Google recommends over every other kind. On link value, Google is direct: 301 and other permanent redirects don't cause a loss in PageRank.
Three details matter as much as the redirects themselves:
- No chains. Each old URL should point straight to its final address. Googlebot can follow up to ten hops, but Google advises keeping chains to three at most, because every hop slows the page for the traveller too.
- Canonical tags on the new site. Each new page should name itself as the canonical version.
- Language tags (hreflang). If your site has several language versions, the tags that tell Google which page is the Dutch version of which English page need to point to the new URLs.
Step 5: Protect the path to the booking engine
Rankings get the attention, but bookings are what you would actually lose. A traveller who lands on the new site and clicks "Book" has to arrive in your booking engine with the room and dates they were looking at, exactly as before.
Before launch, test every booking button on the new site, in every language, on a phone. After launch, update the links you control outside the site: your Google Business Profile, your social profiles and any ad campaigns. Google's guide lists profile links and ad campaigns among the first things to change once the move starts, because a redirect is slower for the traveller than a direct link.
This matters more now that Booking.com can no longer make you match its price. If your direct rate is lower, the traveller has to be able to find it and book it, and a broken booking link throws that away.
A redirect saves your ranking. A working booking button saves the booking.
Step 6: Launch, test, and keep the redirects for at least a year
On launch day, switch on the redirects, remove any noindex tags or robots.txt blocks used while the new site was being built, and submit the new sitemap in Search Console. Test a sample of old URLs with the URL Inspection tool to check each one lands where your mapping says.
Then leave the redirects in place. Google's guidance is to keep them for as long as possible, generally at least one year, so that it can transfer all signals to the new URLs, including links from other sites that still point to the old ones. From a traveller's point of view, Google suggests keeping them indefinitely.
What to expect in the weeks after launch
Some movement in rankings is normal. Google's guide says a small to medium-sized website can take a few weeks for most pages to move, and that visibility may fluctuate during that time before it settles.
What you should see in Search Console is a handover. The old URLs drop out of the index while the new ones rise, and the queries you ranked for start showing the new addresses.
| What you see | What it usually means | What to do |
|---|---|---|
| A rise in "Not found" errors | Redirects pointing to addresses that don't exist | Check the mapping against the live site |
| New pages not indexed | A leftover noindex tag or robots.txt block | Remove it and request indexing |
| Old URLs still showing in results | Google hasn't recrawled them yet | Wait, and check the redirects still work |
| Traffic falls on one language only | Language tags still point to old URLs | Update the hreflang annotations |
| Booking clicks fall but traffic doesn't | A broken or changed booking link | Test every booking button again |
What Hotel Harmony's analytics showed after the switch
Hotel Harmony and Ghent Urbanist are two boutique hotels in Ghent, 77 rooms, run by one team. Both websites were rebuilt in 2026, in three languages. The address stayed the same: hotel-harmony.be, before and after.
The published case includes a full week of Google Analytics for the rebuilt Hotel Harmony site, taken a few weeks after launch. Organic search and direct were still the two biggest sources of visits. In third place, at more than one visit in ten, was Google Analytics' AI Assistant channel, which groups traffic from ChatGPT, Perplexity, Copilot and Gemini.
That week is one snapshot, not a before-and-after comparison, so it doesn't prove rankings held. It does show what a rebuilt hotel site can look like once the move has settled: the traffic it already had still arriving, and a new source that the old site wasn't set up to earn. More on that in why hotels don't show up in AI search.
Where AskWhisper fits
AskWhisper builds the new site from a description of your property, in your own colours, typefaces and photography. It is not a booking engine: your engine, your PMS and your reservations stay where they are, and the site sends travellers into your engine with the room and dates they were looking at. Most properties go live within a few days.
The move itself is part of the job. AskWhisper maps your old URLs to the new pages and sets up the redirects, which covers Steps 1, 2 and 4 above, and helps you connect your domain to the new site through its DNS settings. Registering and hosting the domain itself stays with an external provider of your choice; that isn't included, but the team can help you set it up.
If you are still deciding whether to move at all, our breakdown of what a hotel website actually costs and the comparison with hotel website agencies cover that decision. The website is also where the seven handoffs where independent hotels lose revenue begin.
Afraid of the switch? See the new site first.
Describe your hotel and we build a preview of your new website before you change anything on your live site. Or read how Hotel Harmony rebuilt two sites after nine years on the old one.
Turn lookers into bookers. Just Ask Whisper.
