> For the complete documentation index, see [llms.txt](https://www.oddle.me/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.oddle.me/docs/new-guests/site/what-your-customers-see.md).

# What Your Customers See

Diners hit your Oddle Site when they search for you on Google, click a link from social, or arrive via Oddle Eats. What they see is a full restaurant website designed to do two things: prove who you are, then turn the visit into action.

***

## The pages that come standard

Every Oddle Site has the pages a restaurant actually needs — built in, not opt-in:

* **Home** — Brand story, signature photography, hours, and the three things diners care about most: where, when, how to come.
* **Menu** — Your live menu, pulled from your Oddle Shop menu data. Always current, no separate menu PDFs to update.
* **About** — Your story, chef profile, press mentions, and reviews. The proof points that turn interest into trust.
* **Contact & directions** — Location, hours, parking, contact, with a map. The information aggregators bury.
* **Book / Order** — Direct entry to Oddle Reserve and Oddle Shop. No middleman.

***

## Built for search

Most restaurant sites lose ranking to aggregators like Tripadvisor, OpenRice, and Wikipedia because they don't have the structured data search engines need. Oddle Site fixes that out of the box:

* **Restaurant schema** — Diners searching "\[your restaurant] menu" or "\[your restaurant] hours" see the right page first.
* **Google Places location data** — Accurate address, map, and place details are pulled from Google so your contact and directions match what diners see on Maps.
* **Built to be searched in your guests' languages** — Your site serves the languages diners actually search in for your market.
* **Fast** — Sites are server-rendered and load fast on mobile, which Google rewards.

You don't configure any of this. It's how the product works.

***

## Every visitor is a potential known guest

Bookings, orders, and signups are built into the site:

* **Book a table** — Diners book through Oddle Reserve. Bookings land in your Host App.
* **Order online** — Diners order through Oddle Shop, with your live menu data.
* **Sign up for offers** — An email signup that creates a customer in your Oddle database — so even diners who aren't ready to book today can be marketed to tomorrow.

Every action ties back to a single customer profile in your Oddle database, just like Reserve, Shop, and Check-in. The diner who reads your menu and books on Friday is the same profile your marketing automations follow up with the next week.

***

## What diners don't see

* **Ad networks or surveillance trackers** — The only analytics is privacy-friendly visitor measurement (Umami), used to give *you* a traffic dashboard. No ad networks, no reselling diner data.
* **Stale menus or outdated hours** — Menu shares your live Oddle data. Holiday closures and promo banners can be pushed by your team in minutes.
* **"Coming soon" placeholder pages** — Oddle Site goes live complete or not at all.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://www.oddle.me/docs/new-guests/site/what-your-customers-see.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.