Renewing a hotel website without losing search traffic: a migration checklist

A hotel website migration is a move to new addresses: a new domain, new page paths, or a switch to HTTPS. To keep search traffic, map every old address to its new one, redirect permanently and one to one, keep language and room pages, test the booking path, then watch Search Console for weeks after launch.

The new site goes live on a Monday. By Friday the reservations inbox is quieter, and the room pages that used to appear on the first page of results have gone. In most cases nothing is wrong with the design: the old addresses simply stopped working. This checklist follows Google's own site-move guidance, so you can hold a supplier to a list rather than a promise. Work through it in order: inventory, map, redirect, test, then monitor.

Why do hotel rankings drop after a new site launches?#

Because the addresses search engines already know stop returning a page, and the new addresses stay unknown until they are crawled, redirected and confirmed.

A renewal usually changes addresses: a room page moves from one path to another, the domain changes, or the site moves to HTTPS. Each old address is a page already in the index, and a ranking attached to an address that now returns "not found" has nowhere to go. The new page has to earn its place, and that takes crawling time.

Four launch-day mistakes cause most of the damage, and all four are avoidable:

The staging problem deserves a word. Suppliers often build the new site with an instruction that tells search engines not to index it, which is correct during the build. If nobody removes that instruction before launch, the new site stays invisible while the old one is gone. Check this before anything else.

Changing design, wording, addresses and domain in the same week removes your ability to tell which change caused a drop. Google's guide advises changing one thing at a time, and moving in a low-traffic period. Small and medium sites should move all addresses at once rather than in stages. Before touching addresses at all, settle the domain, certificate and ownership checks, because a move is the wrong week to discover a lapsed registration.

The fall is often temporary. The guide states that rankings may fluctuate and that a medium-sized site can take a few weeks or more before the new addresses appear instead of the old ones. A hotel feels this commercially before it sees it in a report: the room pages that carried the brand name and the city name lose position first.

Before the move: which old pages actually bring visitors?#

Start from a complete list of every address on the current site, then mark the ones that bring organic entrances, because those are the pages a redirect must not lose.

Build the list from three sources: the current sitemap, a crawl of the live site, and the pages Search Console reports as receiving clicks and impressions. A sitemap alone misses pages added by hand or by a previous supplier. A crawl finds them.

Mark every page by type: home, room type, restaurant and bar, spa, meeting rooms, offers, gallery, contact, and the legal pages such as the privacy notice and facility disclosures. Mark every language version separately. A hotel publishing in Turkish, English, Russian and German has four addresses for each room page, and each one needs its own destination.

Flag pages that earn links from outside: a local news piece, an association listing, a wedding blog, a tour operator page. Those addresses are worth keeping alive even when the page itself is retired. Then decide the fate of each page before design work starts: keep, merge into another page, or retire. A retired page that still receives visitors should redirect to its closest replacement, not to the home page.

Freeze the list. Any page added during the build goes onto the same list, with the same fields.

How do you build a one-to-one address map, language by language?#

One row per old address, one destination per row, and a language column so that no version is quietly dropped.

The columns that matter: old address, page type, language, monthly organic entrances, new address, redirect type, who owns the row, and a checked box. Never send several old addresses to one new address unless the pages genuinely merged. Google's guide warns that pointing many old addresses at one irrelevant page, such as the home page, can be treated as a soft 404, meaning the destination is read as missing content.

Languages must pair correctly: the Turkish room page goes to the Turkish room page, not to the English one. A working redirect to the wrong language still loses the visitor. Room type pages carry the most commercial value, so check that every old room address has an exact counterpart, including rooms that were renamed or are only sold in season.

Keep the old address pattern where the new site allows it. If a room page can stay at the same path, the map becomes trivial and the risk drops sharply. Finally, put the map in the contract as a deliverable with a date, not as a favour requested after launch.

For example, a small map might look like this:

What is a redirect, and how do you test it?#

A redirect is an instruction on the server that sends a visitor and a search engine from an old address to a new one; a permanent redirect passes the signal, a temporary one does not.

Ask for server-side permanent redirects, the kind known as 301 or 308. Google's guide treats client-side redirects, the kind a page script performs after loading, as a last resort because they are slower and easier to get wrong. Redirect straight to the final destination: Googlebot will follow up to 10 hops, but the guide says a chain should ideally have no more than 3, and fewer than 5. Keep the redirects for as long as possible, generally at least one year, because old links in printed material, partner listings and email signatures keep arriving long after launch.

Testing is simple. Type the full old address into a browser and read the address bar: it should show the final destination, not an intermediate one. Test the language versions and the room pages first, then a sample of at least twenty other pages, including one page you expect to be retired. Ask the supplier for a report listing every old address, its destination and the response the server returns, and keep that report with the contract.

What else breaks on launch day: booking engine, analytics and ad landing pages?#

The booking path, the tracking and every paid landing page sit outside the page templates, so they are the parts a design review never checks.

Walk the booking path end to end: room page, availability, rate selection, guest details, confirmation. A correct redirect on the room page is useless if the booking button still points at an old engine address. Confirm the analytics code sits on every template, including the confirmation page, and that old and new addresses are not counted twice during the overlap. Update every campaign that points at a specific address, or the budget pays for a redirect instead of a landing page.

Check the Google Business Profile the same week: the website link and the booking link must point at the new site, and the profile is often the first result a guest taps. Fix internal links too: menus, footers and the cross-links between language versions must use the new addresses, not the old ones. Update the external links you control, from association listings and tour operator pages to email signatures, invoices and printed QR codes. Finally, recheck the legal and content pages in every language against the hotel website checklist for content, legal information and the booking path: privacy notice, facility and distance disclosures, contact details, and the booking terms.

What should you check in the first 30 days after the move?#

Watch old and new addresses in Search Console, fix what the reports show, and expect movement rather than a straight line.

Submit the new sitemap on launch day, and confirm that no instruction blocking search engines from indexing survived the move. Submit a Change of Address in Search Console only when the domain or subdomain changed: Google's guide says it is not needed for HTTPS moves, www/non-www switches or path moves inside the same domain. Check that the canonical tag on each new page points at the new address in the same language, and that no canonical still points at the old or staging address.

Monitor traffic on old and new addresses together: a fall on the old and a rise on the new is the expected shape, while a fall on both is a problem to investigate. Run a broken-link check weekly for the first month and add every miss to the redirect list rather than fixing pages one by one. Do not change titles, wording and structure again during those weeks, or you will not be able to read the result of the move.

Once the move settles, the ongoing work begins: page structure, local search and the technical basics that keep a site findable, covered in the hotel website SEO checklist.

What to do next#

Ask your web supplier for two documents before you sign: the address map, one row per old page and language, and the redirect report produced after launch. The rest of the work follows that order: inventory what brings visitors, map it, redirect it permanently, check the systems around the pages, then read Search Console for a month before changing anything else.