The short answer
Before a relaunch, secure the complete list of all previous addresses with their page views, all texts and images at original size, the access to the booking system, analytics and business profile, and a working backup of the old site. Switch over in a fixed order, with redirects on the day of the change and a test booking before and after.
Key takeaways
- The address list with page views is the most important document in the project, because it determines which redirects are needed.
- Back up images at original size, not the cropped versions from the old system.
- Redirects go to the content-wise matching page, never blanket to the home page.
- The booking connection is checked before and after the switch with a real test booking.
- Losses show up as error pages, as individual pages losing visits, and as inbound links that lead nowhere.
Before moving a hotel website, four things should be secured: the complete list of all previous addresses with their page views, all texts and images at original size, the access to the booking system, analytics and business profile, and a restorable backup of the old site. After that, the switch happens in a fixed order, not on a Friday afternoon. How a website with live availability and its own booking flow is built overall is shown on the service page website with its own booking flow.
The losses a relaunch causes rarely happen on switch-over day. They happen in the weeks before, when nobody writes down what exists.
The list of all addresses is the most important document
Every page of your old website has an address, and some of these addresses exist elsewhere: in a portal profile, on a regional page, in an old confirmation email, in a newspaper article, in a bookmark. If the address leads nowhere after the move, that route to you is broken.
So first draw up a complete list: all addresses from the sitemap, from the analytics tool with page views for the last twelve months, and from Search Console. Sort by views. Whatever is at the top needs a counterpart in the new site, as the same page, as a better successor or as a redirect to the content-wise nearest page.
Redirecting all old addresses blanket to the home page is not a plan but the opposite of one. The guest who was looking for a particular suite lands at the start and has to search again.
Content and images: what actually moves across
Copy the texts from the old system completely before the first template is ready, including those you do not intend to take over. It is astonishing how often a ten-year-old directions description contains a detail that nobody else knows any more.
For images, back up the originals, not the cropped versions the old system delivers. Note who made them and how long the usage rights run. Image captions, alt texts and file names should be backed up too; they are work that has already been paid for.
Also back up menus as files, price sheets, house rules, directions sketches, voucher templates and forms with their recipient addresses. The form inbox in particular is regularly forgotten, and then the new site sends to an address nobody reads.
Also note which language versions exist and which of them are maintained. Half-translated pages rarely survive a move intact, and it is easier to decide beforehand which language comes along than to explain an incomplete version afterwards.
Links from outside and your profiles
Besides your own pages, there are places where your address appears outside: the Google business profile, the portal profiles, the regional tourism board's page, partner businesses, press articles. Draw up a list of these places and check each one after the move.
Reviews themselves do not move; they stay with the platforms. Whatever is embedded on your website must be reconnected after the switch. Also check whether your contact details are written identically everywhere: same name, same address, same phone number. If you change from "Hotel" to "Boutique hotel" in the relaunch, do it in the profiles too.
The booking connection is the riskiest part
Two things go wrong here. First, the connection to the booking system breaks because the new site sits at a different address or a script was not moved along. Second, the booking flow still runs but writes into a test account or with wrong prices.
Therefore: one real test booking with a real payment on the day before the switch in the old system, and another immediately after the switch in the new one, each on a phone, outside the property's Wi-Fi, and cancelled afterwards. Also check whether the confirmation email is delivered and whether it carries the correct sender details. How this booking flow should be built is covered under booking flow with online payment.
Working through this for a property with 26 rooms
An established website for this property has 180 addresses: rooms, offers, blog posts from eight years, archive pages, files. The analytics tool shows that 96 of them were visited at all in the last year; the remaining 84 can be dropped without replacement.
For each of the 96 addresses you determine a target page. Three minutes per address, including checking and entering, add up to roughly five hours of work. That is the full price for keeping the existing visits, and it is paid once. Whoever saves these five hours pays for them over months in the form of visitors who land on an error page. The figures are an example of a medium-sized property; your own list may be shorter or considerably longer, but the method stays the same.
Switch over in this order
First build the new site completely on a non-public address and proofread it there: texts, prices, times, phone numbers. Then enter the redirect list and check it on the test version. Then choose a switch-over date early in the week and outside the arrival peak.
On switch-over day: switch, call up redirects at random, run a test booking, send forms, resubmit the sitemap. In the days after: check the error pages every day. Keep the old site backed up until four weeks have passed, not until everything looks good.
What should grow technically during this process is the markup of your content with structured data, so that search engines can read rooms, prices and location [Q1]. The vocabulary for this is described by Schema.org, with its types for hotels and rooms [Q3]. How far that goes is covered under structured data for AI search.
How to tell whether something has been lost
Four signs, in this order. First, error pages: Search Console reports addresses that are no longer reachable after a few days. Second, individual pages whose views fall to zero after two to four weeks while the total barely changes, which is why you compare page by page, not in total.
Third, inbound links that lead nowhere: go through your list of profiles and partner sites once. Fourth, missing enquiries: if nothing has come through the contact form since the move, the cause is rarely the market.
Speed should be checked as well. A new site is not automatically faster than the old one, and Web Vitals provide the measures for this [Q2]. Measure before and after the switch, otherwise you have no comparison.
What you need to handle yourself
Nobody outside the property knows which details are correct. Checking prices, times, facilities, house rules and directions is your job, and it takes longer than expected. Plan two appointments of two hours each for it, one before the proofreading and one after.
Then there is the decision about which content is dropped. A relaunch is the only moment when deleting comes easily; afterwards everything stays online again. What is technically and content-wise wrong today is shown by a technical check of the hotel website, before you decide whether a relaunch is needed at all.
When a relaunch is not the answer
If your site is slow, has no booking flow or breaks on mobile, these are three separate problems with three solutions, and a complete rebuild is the most expensive route for that. If the content is correct and only the look feels dated, a new design on the existing foundation is often enough.
A relaunch pays off when the structure no longer holds: when new pages cannot be sensibly placed, when the system no longer receives updates, or when nobody can maintain content any more without causing damage.
Next, pull the list of your addresses with last year's page views and mark the thirty most important. On this basis, the relaunch of your hotel website can be planned without losses. Book an appointment.
Sources and further reading
[Q1] Google Search Central: Introduction to structured data
[Q2] web.dev: Web Vitals
[Q3] Schema.org: Hotel
Häufige Fragen
How long should the old website stay reachable after the move?
The old website itself is switched off as soon as the new one is live, since two versions reachable in parallel cause confusion. What must remain is the complete backup, for at least four weeks, better six months. During that time, content surfaces that nobody noticed during the move, and it can be added afterwards.
Who looks after the redirects, the agency or the host?
Either can enter them, but one party must be accountable. Before the project, decide who maintains the list and who checks the error pages after the switch. In practice the agency creates the mapping and the property checks it for content, because only someone in the property knows which old offer page corresponds to which current offer.
Will I lose my search engine rankings in a relaunch?
With clean redirects and unchanged content, expect temporary fluctuations rather than a lasting loss. It becomes risky if content is heavily cut, addresses are dropped without replacement, or the new site is noticeably slower. No one can responsibly promise rankings, so be wary of anyone who does.
What do I do with old blog posts that nobody reads?
First check the page views of the last twelve months. Posts without views and without links from outside can be dropped. Posts with few but steady views are worth revising rather than deleting. Anything that points to an offer that no longer exists is either updated or redirected to the matching current page.
Talk to us
Direct booking, without the commission
We build the booking site, connect it to your channel manager and keep it running.
Book a first call