Site Structure That Leads Straight to Booking

Introduction

When you build a site for your property, it's tempting to start from "a beautiful page full of great photos." But if direct booking is the goal, the thinking has to run the other way: every page is a corridor leading to the booking.

In this article, we share the page structure and information architecture we put into practice on the official site of a private rental villa in Japan's Seto Inland Sea area — including four-language support and search engine optimization (SEO), explained so a non-engineer can follow along.

Splitting the site into three zones

Public pages, the booking flow, and guest-only pages

We built the site as three zones with genuinely different characters: public pages anyone can see, the pages that handle the booking process, and pages only confirmed guests can use.

There's a reason for splitting things this way. Booking flow pages generate endless URLs from combinations of dates and party sizes, so putting them in a search index just creates a pile of duplicates. And guest-only pages contain sensitive information like entry instructions, so we isolated them from search engines and configured them to leave no cache behind.

Put an exit toward booking on every public page

If someone reads the property intro and thinks "I'd like to stay here," it's all wasted unless they can move to booking right then. So on mobile we pinned a booking button to the bottom of the screen, and on desktop we keep a discreet tab parked at the edge.

Whatever page you're reading, the exit toward booking is always one tap away. That consistency of exits is, we think, the single biggest difference between a brochure site and a booking site.

Keep factual information in one place

Check-in time, maximum occupancy, number of parking spaces, cancellation terms — these facts appear on many pages. Write them directly into each page, and you'll inevitably miss one when something changes.

So we consolidated all factual information into a single configuration file that every page reads from. Want to change the check-in time? Edit one place. The FAQ, the booking pages, and the emails all fall in line automatically. It's unglamorous, but the longer a site runs, the more this design pays off.

How we approached four languages

Deciding the relationship between URLs and languages

To welcome guests from overseas, we support Japanese, English, Traditional Chinese, and Korean. Language is expressed in the URL, with only the default language left unprefixed: Japanese is /villa, English is /en/villa.

Each page also automatically embeds the cross-language mapping (hreflang) that says "here's the English version of this page," so search engines understand the language variants correctly.

Preventing missing translations by design

Managing four languages across every page by hand simply isn't realistic. We separated all text into per-language dictionary files, so pages only say "put the text for this key here."

For content updated day to day — blog posts and announcements — we built a feature into the admin panel where you write in Japanese and AI translates into the other three languages (covered in detail in the CMS series).

Getting along with search engines

Using structured data to say "this is lodging"

Search engines don't just read your prose; they also read structured data (JSON-LD) that says "this site is a lodging facility, it's located here, and these are its FAQs." We embedded lodging structured data on the property pages and FAQ structured data on the FAQ page.

That opens the door to standing out in results — for example, having your FAQs expanded right there in the listing.

Being clear about what to show and what to hide

The sitemap (the file that tells search engines which pages your site has) lists only the public pages plus blog and announcement posts. The booking flow, admin panel, and guest-only pages are excluded.

The important part is not relying on robots.txt (a file that politely asks search engines to stay away) to protect confidential pages. Real protection comes from authentication and noindex; robots.txt is only a supporting measure.

Wrapping up

Three things mattered most in designing the pages of a direct-booking site.

1. Think in three zones — separate public, booking flow, and guest-only, and treat each differently
2. Facts in one place — consolidate check-in times and policies in a configuration file so nothing gets missed
3. Language and search both start with URL design — split four languages by URL and be clear about what to show and what to hide

The screen design of the booking flow itself is covered in "Building Our Own Booking Screens," and how we built the area guide page in "An Area Guide Powered by the Google Places API."