Restaurant hosting for the twelve o'clock rush.
A restaurant site is quiet all morning and then everybody within a mile opens it at once, on a phone, looking for one thing.
One page, twice a day.
Almost all of a restaurant site's traffic is the menu, the hours and the phone number, arriving in two narrow windows.
A menu change that is live immediately
Running out of a dish is a same-minute problem. Menu pages purge on save, so the version a customer reads is the one the kitchen can actually cook.
Opening hours that are right today
Hours, holiday closures and location are what people actually came for, and they are served as structured data so search results and map listings show the same thing the site does.
Ordering and booking widgets that respond
Most venues embed a third-party ordering or reservation system. Those scripts are loaded so a slow supplier degrades one panel rather than blocking the whole page.
Food photography that loads on 4G
Restaurant sites are image-led and read outside on a phone. Photographs are processed on upload so a hero image is not a five megabyte download.
Two rushes, not a curve
Traffic arrives around midday and again in the evening. Capacity is planned for those windows rather than the flat daily figure.
Found on a phone, outside, in a hurry.
Nobody browses a restaurant website. They check whether it is open, what is on, and where it is - and they do it standing on the street.
- Menu pages purged the moment they are saved
- Hours and address served as structured data
- Third-party embeds isolated from page render
- Images processed for mobile connections
Fast enough to beat the app.
The competition is a delivery app that already has the menu. A site that takes four seconds on a phone has lost before it has loaded.
What we change for restaurant sites
Small site, narrow traffic windows, and a handful of pages that carry everything. The tuning follows that shape.
| Setting | What we do | Why |
|---|---|---|
| Menu cache | Purged the moment a menu page is saved | A dish being unavailable is a same-hour change, and a menu cached for a day sends people in for something the kitchen cannot make. |
| Local structured data | Hours, address and phone rendered server-side | Most people never reach the site - they read the hours in a search result, and those come from markup that has to be in the served HTML. |
| Third-party embeds | Loaded so a slow supplier cannot block the page | Ordering and reservation widgets are somebody else's infrastructure, and a synchronous embed makes their bad afternoon into your blank page. |
| Image processing | Sized for phones at upload time | Food photography is the point of the site and it is viewed on mobile data outside the venue, so the delivered file has to be small without looking it. |
| Capacity windows | Planned around midday and evening peaks | A restaurant's traffic is two spikes a day rather than a curve, and a daily average hides both of them. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
How quickly does a menu change appear?
Can I use an external ordering or booking system?
Why do my opening hours show wrong in Google?
Do I need much capacity for a single restaurant?
Be open before the app is.
Move the venue site across - migration is free, menus included.