Vertical · Restaurants & Food Service

Hungry people decide in 90 seconds. Make every second count.

Someone choosing where to eat tonight opens your site on their phone and runs through the same three-step check every time: can I read the menu, do the photos look good, are you open and can I get a table? If your site fails any of those in the first scroll, they go to the restaurant with the better website. Not necessarily the better food. A hand-coded site built around how the restaurant decision works on mobile, not around what website builders default to.

Get a quote See pricing

The 3 things people check before deciding where to eat

Restaurant web design gets a lot of discussion about branding and photography and "telling your story." What it rarely covers is the actual mobile behavior of the person choosing where to eat on a Tuesday night. That person is not reading your About page. They are doing three things in roughly 90 seconds, and the structure of your page either accelerates that decision or kills it. Here's the sequence and exactly where most restaurant sites fail in each step.

First: they check the menu

The menu is the most important page on a restaurant website and the most consistently mishandled one. Two bad approaches dominate: a PDF, and a menu loaded in from an outside service. Both look like solutions, but neither works on a phone in the hands of a hungry person.

A PDF menu requires the user to tap a download link, wait for the file to transfer, open a PDF reader, deal with a landscape-oriented layout designed for print, and pinch-zoom to read half the items. That's five steps before they've seen a single dish. On a mid-range Android on a middling LTE connection at 7pm, the PDF either takes too long to load or renders poorly in a browser. Most people don't finish that sequence. They back out and open the next tab.

A menu loaded in from a third-party service (BentoBox, SinglePlatform, Square's hosted menu) looks cleaner but has two problems: it adds its own separate load time on top of your page's. More critically, the menu text is walled off inside that outside service and is completely invisible to Google. That means when someone searches "restaurants that serve [specific dish] near me," your menu can never appear in the result. A PDF can't either. A menu built directly into your own page can, because Google reads every word of it.

The right approach is a menu built right into your own page with your sections (Starters, Mains, Sides, Drinks, Desserts), item names, descriptions, and prices. It loads in under a second, fits a phone screen perfectly without any zooming, and every dish name and description is something Google can find. Seasonal updates, 86'd items, and price changes happen in a simple text file: no clunky content system to log into, no waiting, no invoice.

Second: they look at the food photos

Food photos aren't decoration on a restaurant website. They're the pitch. A prospective diner is running a visual confirmation test: does this food look like something I want to eat tonight? That check happens fast and it's emotional, not analytical. A gallery of well-shot food photos closes it in seconds. A page that takes six seconds to load while the photos bleed in one by one does not.

The most common speed problem on restaurant sites is food photos that were never shrunk for the web. A professional food photographer delivers enormous, print-sized images. A phone shoots photos that are 4 to 6 megabytes each. Both get dropped onto the site at full size. Load six of those on a homepage and you have a page that weighs 30 megabytes before anything else even starts. On a phone on a decent connection, that page takes 8 to 12 seconds to fully appear. By second four, most people have already backed out.

Three things fix this: converting photos to a modern image format that's far smaller without looking any worse, sending each device a right-sized image (phones download smaller files), and loading photos only as visitors scroll to them. Together they bring that same homepage to under 8 megabytes on mobile without any visible quality change. The food still looks exactly as good. The site loads before people give up. This single fix has more impact on whether people actually choose your restaurant than any amount of redesign.

Photo placement matters too. Most restaurant sites isolate all imagery in a gallery separate from the menu. A customer reads your mushroom risotto description on the menu page and then has to navigate to a different page to see what it looks like. Many won't bother. They'll make a decision on the description alone, which is a weaker sell. Embedding dish photos adjacent to or within menu sections closes that gap and moves people from "sounds interesting" to "I want that" without adding navigation friction.

Third: they confirm hours, location, and how to get a table

The person has seen the menu, liked the photos, and now needs to know three things: are you open right now, exactly where are you, and how do I get in? This is the moment where a lot of restaurant sites lose customers they already had because the information is either wrong, buried, or both.

Hours are the most failure-prone element on restaurant websites for one specific reason: they change. Kitchens close early on slow nights. Holiday hours get added and never removed. A pandemic reduction in hours from three years ago still sits on the footer of a site nobody updated. A site that shows you're open until 10pm when you close at 9pm doesn't just inconvenience one customer; it trains people to stop trusting your website and call instead. That's worse for everyone, including your staff.

Hours should appear in at least two places: the main homepage and a dedicated Contact or Location page. They also need behind-the-scenes labels that tell Google exactly when you're open, so it can display your hours accurately in search results and Maps without the customer needing to visit the site at all. If the hours Google reads from your site don't match the hours on your Google Business Profile, it may display whichever it trusts less — which can be wrong.

Location needs a clickable address that hands off to Google Maps or Apple Maps navigation (not just text, not a static screenshot of a map—an actual tap-to-navigate link). Reservations or ordering need to be in the site navigation and visible in the hero section on mobile without scrolling. If someone has to hunt for the Reserve button, you've already introduced enough friction that some of them won't find it.

What a restaurant website needs to do

A restaurant site has a tighter job than most small business websites. It's not trying to explain a complex service or educate a slow-moving buyer. It's answering six specific questions from a person making a fast, mobile decision. Each one either works correctly or it becomes a reason to choose somewhere else.

A real menu page, not a PDF

Full menu built right into a clean, phone-friendly page with your sections organized by service (brunch, lunch, dinner, happy hour, drinks, desserts), item names, descriptions, and current pricing. Every dish is something Google can find and show in search. The page loads in under a second on a phone. Specials, 86'd items, and price changes happen in a simple file: no developer call needed, no technical editing required. Dietary tags (vegetarian, vegan, gluten-free, contains nuts) can be added per item for guests with restrictions who are pre-checking before they book.

Location, hours, and contact

Hours displayed prominently, plus behind-the-scenes labels that tell Google your hours so it can show them in search results and Maps without the visitor needing to visit the site. Tap-to-navigate address links that hand off directly to Google Maps or Apple Maps. Tap-to-call phone number. Directions from major nearby landmarks or intersections for restaurants in neighborhoods where the exact address is less useful than knowing "we're next to the parking garage on 5th." Hours in at least two places — the homepage footer and a dedicated Contact or Location page — so they're findable regardless of which page someone lands on.

Reservations and ordering — visible immediately

Whichever platform you're on — OpenTable, Resy, Toast, Square Online, DoorDash Storefront — built in or linked with a prominent button in the site navigation and at the top of the page, visible on a phone before anyone scrolls. Not in the footer. Not buried in a Contact page. The reservation or order button needs to be visible the moment someone decides they want to come, because that decision is made at the top of the page, not after reading everything. Third-party platform integrations are included at no extra cost.

Fast food photography

Food photos are the heaviest part of any restaurant page and the ones that most decide whether someone chooses you, which creates a specific problem to solve. Every image is converted to a modern format that's far smaller without looking any worse, each device gets a right-sized version (phones download smaller files instead of full desktop originals), and photos further down the page load only as visitors scroll to them. Your main photo is told to start loading first, before everything else, so it appears in under a second. The result: a clean pass on Google's page-speed and stability health checks on mobile, which factors into your local search ranking, and a site that keeps people engaged long enough to finish checking the menu.

Local SEO built in from the start

Behind-the-scenes labels that tell Google exactly what your business is — your name, address, phone number, location, cuisine type, price range, and accepted payment methods. A review against your Google Business Profile to make sure every fact on your site matches your listing exactly, because mismatches between the two reduce trust in both. A check that your name, address, and phone are identical on every page. A map of your site handed to Google on launch day. For neighborhood searches ("best Thai near downtown"), having your individual dishes readable by Google gives you ranking reach that restaurants with PDF menus or menus loaded from outside services never get. Restaurants are one of the highest-intent local SEO verticals and one of the most competitive. This stuff matters.

Events, specials, and private dining

Happy hour pages with specific day and time windows. Weekly specials that rotate. Prix fixe menus for holidays. Private dining inquiry forms with room capacity, A/V availability, and minimum spend. Live music or entertainment schedules. This content does two jobs: it gives repeat customers a reason to check the site between visits, and it gives search engines something fresh to read. Event pages with the right behind-the-scenes labels can appear directly in Google search results showing the event date and time — a feature most restaurant sites never set up and a free visibility boost for anyone who does.

Ordering and reservation integration: what works and what to watch for

Third-party ordering and reservation platforms are a practical reality for most restaurants, and integrating them well is one of the highest-leverage things a restaurant site can do. Integrating them poorly (a broken widget, a hidden link, an embed that destroys mobile performance) costs you customers at the exact moment they were ready to transact. Here's how to evaluate each platform and make the integration work.

Online ordering platforms

The right ordering integration depends on what POS system you're running and whether you want delivery, pickup, or both. The major platforms at the independent restaurant scale:

Toast Online Ordering — the natural choice if you're already on Toast POS. Orders flow directly into the kitchen display system with no manual re-entry and no tablet relay. The storefront can be built into your site or linked out to a Toast-hosted page. Commission-free for orders placed through your own domain (commissions apply for orders sourced through Toast's marketplace). If you're on Toast, start here — the ordering experience is tightly integrated with your actual kitchen workflow.
Square Online — tight integration with Square POS and Square Payments. The ordering page can embed under your own domain or live as a Square-hosted storefront linked from your site. Strong for counter-service, fast-casual, and cafes already running Square terminals, where the payment flow is already Square-native. Less suited to full-service restaurants with table-assignment complexity.
DoorDash Storefront — DoorDash's white-label ordering product. Customers order through your branded storefront, DoorDash handles delivery logistics, at a lower commission rate than appearing on the main DoorDash marketplace. Worth considering if you want to offer delivery without building your own driver network or contracting a separate courier. The storefront embeds cleanly or links from your site with minimal setup.
Yelp Online Ordering — integration for restaurants already active on Yelp with meaningful review volume. Lower reach than Toast, Square, or DoorDash Storefront for direct orders, but useful for capturing customers who discover you through Yelp reviews and want to order without switching to a different app or site. Works best as a secondary channel, not a primary ordering solution.

Reservation platforms

For table reservations, the two platforms that matter most at the independent restaurant scale are OpenTable and Resy. They're not interchangeable.

OpenTable — the highest-reach reservation marketplace in the U.S. A strong OpenTable presence with a high Diner Score and substantial review history drives a meaningful share of discovery for restaurants in competitive markets. The OpenTable widget embeds cleanly in most site layouts and loads without significant delay. Per-cover commissions apply for covers sourced through OpenTable's marketplace; direct bookings from your own site may be commission-free depending on your plan tier. If you're in a market where diners habitually use OpenTable to find restaurants (most major cities), not being on it is a meaningful visibility gap.
Resy — popular with independent full-service restaurants, tasting menu formats, and chef-driven concepts that want more control over the reservation experience. Smaller marketplace footprint than OpenTable but a more polished product for managing the guest experience and communicating with diners before their visit. The Resy widget embeds well and the brand has strong recognition in the fine dining and independent restaurant segment. If your concept skews experience-first over volume, Resy fits the positioning better than OpenTable.
Yelp Reservations and Waitlist — the third option, most useful for restaurants where Yelp is already a top traffic source. The waitlist integration pairs with the reservation widget. Worth adding if your Yelp listing drives a meaningful number of visitors and you want to capture them without requiring a redirect to OpenTable or Resy.

Build it in or link out: the tradeoff

Every platform lets you either build the ordering or booking step right into your page, or send people out to the platform's own page with a link. The right call is not the same for every platform or every restaurant.

Building it in keeps the customer inside your site's look and feel from the moment they land through to a confirmed order or reservation. There's no disorienting moment of "wait, did I just leave the restaurant's site?" Visitors who stay in one consistent experience the whole way through are more likely to finish than those bounced out to some other website partway. Toast and Square Online both build in reliably, and OpenTable's booking step is stable and loads without delay.

Linking out is the better call when a platform's built-in version drags down your page speed, when it doesn't size correctly on a phone, or when the platform's own page is simply a better experience. A large, prominent "Order Online" or "Reserve a Table" button at the top of the page and in your navigation (styled to match your brand, impossible to miss, opening the platform in a new tab) works well because the intent is already there. Visitors aren't confused: they tapped a button that said exactly what it does. Don't force something into the page just because the platform offers it. The goal is the easiest possible path to getting the order or booking done.

The commission math over time

Every per-order commission platform takes a percentage of every transaction indefinitely. At low volume that's fine. At meaningful online order volume (say, 200 orders a month at an average of $35), a 6 percent commission is $504 a month, every month, forever, for something you could own outright. A custom ordering app built through ArdinGate Studios owns the ordering relationship entirely: no per-order commission, direct customer data, push notifications for specials and promotions, and a branded experience that can't be replicated by the restaurant across the street using the same DoorDash Storefront template. The website and app can be built as a bundle. The site goes live first on a faster timeline; the app follows when the volume justifies it.

Making a food-photo-heavy site fast on mobile

Food photography is how a restaurant sells itself to someone who hasn't been there. It's also the fastest way to destroy a site's mobile performance if you don't handle it with intent. The tension is simple: food photos need to be large enough to look good, and large images are heavy. Here's how to resolve it without compromising either side.

1

A modern image format that's far smaller

The usual photo format from food photographers and phone cameras hasn't changed in decades. There's a newer one that looks just as good but takes up far less space. The difference is big: a food photo that's 2.8 megabytes in the old format generally comes in at 1.2 to 1.6 megabytes in the new one, with no visible quality loss on a phone screen. At that ratio, a restaurant homepage with six food photos up top and twenty more in a gallery goes from 65 megabytes of images to roughly 28 megabytes before any of the other improvements below are applied.

It works everywhere that matters: every major browser people actually use (Chrome, Safari, Firefox, Edge) has supported this format for years, and on the rare old browser that hasn't, your visitor automatically gets the older format instead so they always see a photo. The conversion is done once when the site is built, the smaller files sit ready on the server, and the right one gets served automatically — no add-ons, no extra services, nothing slowing the page down.

2

Each device gets a right-sized photo

A full-width food photo on a big desktop monitor is huge — roughly 2,560 pixels wide. On a phone, that same photo only ever shows at a tiny fraction of that size. There's no reason for the phone to download the giant desktop version just to shrink it down — that's more than six times the image data the screen can actually show.

So the site keeps several sizes of each photo on hand and hands every visitor the one that fits their screen. A phone downloads the small file. A desktop downloads the big one. The photo looks right on both. For restaurant sites where the top of the page is almost always a full-bleed food photo, this one thing cuts how much a phone has to download on a first visit by 40 to 60 percent. Most restaurant sites built on Squarespace or basic WordPress themes don't do this — they load the full-size image on every device. You can usually tell, because those sites feel slow on a phone.

3

Photos load as visitors scroll, so the page feels instant

When someone opens your restaurant's homepage, there's no need to download every single photo on the page right away. All that matters at first is the handful of photos actually on screen — the one up top, maybe one or two more. Everything further down the page is told to wait and load only as the visitor scrolls toward it.

The practical impact on a restaurant site with a big photo up top, a gallery of twenty food photos, and menu section images: instead of trying to pull down all twenty-three images at once, the page only loads the three the visitor can actually see. The other twenty come in steadily as they scroll, usually arriving just before they reach them. From the visitor's side the page feels fast from the first second.

For menu pages with a photo next to each dish — increasingly common at fast-casual and build-your-own concepts — loading photos only as people scroll is especially important. A menu with 60 items each paired with a photo would otherwise try to pull down all 60 photos the moment the page opens, even if the visitor never scrolls past the first three sections. Loading on scroll cuts that down to just the photos in the section they're actually looking at, and waits on the rest.

4

Your main photo loads almost instantly

One of Google's page-speed health checks measures how fast the biggest thing on screen actually shows up. On a restaurant site, that's almost always your main food photo at the top. Google uses how fast your main photo or headline appears as a factor in mobile search rankings, which for a restaurant competing in local search means it directly affects where you show up in the results.

Three things combine to make that main photo appear almost instantly. First, it's never told to wait — unlike the photos further down, it loads right away. Second, it's flagged as the most important image on the page, so it jumps the line ahead of everything else. Third, your main photo is told to start loading first, before anything else on the page even finishes coming together — which puts it on screen in under a second on a typical phone connection. On this site, that head start is set up automatically for every page that uses a main photo, so it's never forgotten.

5

Put the photos next to the menu, not off in a separate gallery

This one is about getting people to order rather than about loading speed, but it belongs here because it's where restaurant sites most commonly set things up the wrong way. The instinct is to put all the professional food photography in one place (a dedicated Gallery page) and keep the menu page text-only. This means a visitor reading your duck confit description on the menu page has to navigate to a completely different section to see what the dish looks like. The gap between "reads the description" and "sees the dish" is a navigation step, and navigation steps cause drop-off.

Embedding representative food images adjacent to menu sections (or inline with specific high-margin dishes) closes that gap. The visitor reads the description and immediately sees the dish. The conversion from "considering" to "I want to come and order this" happens faster. It also earns you more links from other sites: food bloggers and local journalists who write about restaurants will link to a menu page with photos right on it, because it's more useful to their readers than a link to a plain homepage or a standalone gallery. Those links are exactly what builds your ranking for searches like "best pasta in [city]" over time.

For the standalone gallery, organize imagery by category (brunch dishes, dinner entrées, desserts, cocktails, interior, private dining space, events) so someone looking for a specific type of food or venue shot finds it quickly without scrolling through an undifferentiated grid. Each category should have its own anchor that event planners and bloggers can reference directly.

Pricing

Single-page restaurant sites covering menu, location, hours, contact, and an ordering or reservation link start at $1,200. Multi-page sites with separate menu pages organized by service (brunch, lunch, dinner, happy hour), a gallery, events and specials section, private dining inquiry form, and full ordering or reservation platform integration run $2,800–$5,000 depending on page count and the complexity of the integrations. The search-engine groundwork — the behind-the-scenes labels that tell Google what your business is, a review against your Google Business Profile, a check that your name, address, and phone match everywhere, and handing Google a map of your site — is included with every multi-page build at no extra charge.

Managed hosting starts at $30/month for nightly backups, SSL renewal, and uptime monitoring. Content edits are included starting on the Care plan ($50/month), which covers one hour of edits per month. Menu updates, hours changes, specials additions, and event page swaps are handled for you — email the change, it's live within 24 hours. Most restaurant owners on Care never send a separate invoice for a menu change.

Full pricing breakdown →

Common questions

How much does a restaurant website cost?

Single-page sites covering your menu, location, hours, contact, and an ordering or reservation link start at $1,200. Multi-page sites with separate menu pages organized by service (brunch, lunch, dinner, drinks, desserts), a photo gallery, events and specials pages, a private dining inquiry form, and full integration with an ordering or reservation platform run $2,800–$5,000 depending on page count and how many platforms need to be configured and tested.

The search-engine groundwork is included with every multi-page build: the behind-the-scenes labels that tell Google what your business is, a review against your Google Business Profile, a check that your name, address, and phone match everywhere, and handing Google a map of your site on launch day. Managed hosting starts at $30/month for nightly backups, SSL renewal, and uptime monitoring. Content edits are included starting on the Care plan ($50/month), which covers one hour of edits per month — enough to keep your menu, hours, and specials current without sending an invoice for each small change. Full pricing breakdown →

How do I update the menu after the site goes live?

Two workflows depending on how you prefer to operate. On the Care hosting plan ($50/month), menu edits are included in your monthly content hours: email or text the changes (new item, 86'd dish, price adjustment, seasonal swap) and they're live within 24 hours. No ticket system, no login to remember, just an email. This is what most restaurant owners choose because menus change constantly and nobody wants to be wrestling with a website system at 11pm after a close shift.

For owners who want to handle it internally, the menu can be built against a lightweight PHP data file structured as a simple list of sections, items, descriptions, and prices. You open it in any basic text editor, make the change, and save: no technical knowledge needed, no clunky website system to log into, no subscription portal to forget how to use between visits. Either way, the workflow is built around how your kitchen operates, whether that means quarterly seasonal overhauls or daily specials rotations.

Can you integrate online ordering or reservations into the site?

Yes, and third-party integrations are included at no extra cost. For ordering: Toast Online Ordering (best if you're on Toast POS — orders feed directly into the KDS), Square Online (strongest for counter-service and fast-casual on Square Payments), DoorDash Storefront (white-label delivery at lower commission than the DoorDash marketplace), and Yelp Online Ordering for restaurants with strong Yelp traffic. For reservations: OpenTable and Resy both provide embeddable widgets that work cleanly in a hand-coded site layout. Yelp Reservations and Waitlist are the third option for restaurants where Yelp drives meaningful traffic.

The integration method — embed vs. link — gets decided based on which performs better on mobile for your specific solution. If you eventually want to eliminate per-order commissions by owning the ordering relationship directly, a custom ordering app through ArdinGate Studios is the upgrade path. The website and app can be built as a bundle or in sequence.

Will the site help the restaurant rank in local search?

The search-engine groundwork is included with every multi-page build: behind-the-scenes labels that tell Google exactly what your business is — your name, address, phone, hours, location, cuisine type, and price range; a review against your Google Business Profile to make sure every fact on your site matches your listing exactly (mismatches between the two reduce trust in both and can cause Google to display wrong information); a check that your name, address, and phone are identical on every page; and handing Google a map of your site on launch day.

Restaurants are one of the strongest local-search categories because the intent is immediate and high-commitment. Someone searching "best Thai near downtown" or "romantic restaurant open late" is making a decision in real time. Your Google Business Profile drives placement in the map results for those broad queries. Those behind-the-scenes labels on your site reinforce it and open up rankings for searches the map results don't capture: specific dishes, private dining, neighborhood combinations, and event searches. An active events page and rotating specials section also give Google fresh content to pick up consistently, which helps sustain rankings in competitive neighborhoods. What's included in SEO setup →

How fast can a restaurant site be built?

Single-page restaurant sites — menu, hours, location, and an ordering or reservation link — deliver in 1 to 2 weeks from content handoff. Multi-page sites with a gallery, events section, private dining page, and platform integration take 3 to 6 weeks depending on page count and integration complexity.

The timeline variable is almost always content, not build time. The three things that extend restaurant project timelines most often: menus still being finalized for a new season, food photo shoots that haven't happened yet, and waiting for an ordering or reservation platform to grant the access needed to connect it (Toast and OpenTable can have account approval queues). If your menu, photos, and hours are all ready when the project starts, the shorter end of the range is realistic. Every project starts with a free scope call where the timeline is set against your actual content readiness — no guessing and no committing to dates that depend on things you don't control yet.

How do you make a food-photo-heavy site load fast on mobile?

Four things working together. First, every food image is converted to a modern format that's far smaller without looking any worse — 30 to 50 percent smaller than the usual format. A homepage with six photos up top and a 20-image gallery goes from roughly 65 megabytes to about 28 megabytes before anything else below even touches it.

Second, each device gets a right-sized photo: a phone downloads a small version, not the giant desktop one. Third, photos further down the page don't load until the visitor scrolls toward them, so the only thing the page has to pull down at first is what's actually on screen. Fourth, your main food photo is told to start loading first, before anything else on the page — so the first thing a visitor sees appears almost instantly. That speed is exactly what Google rewards: how fast your main photo shows up is a factor in mobile search rankings, so this affects your local search placement directly, not just how fast the page feels.

What content do I need to provide to get started?

The essentials: your current menu with sections, item names, descriptions, and prices (a PDF, a photo of the printed menu, or a spreadsheet all work as starting points — everything gets rebuilt into a clean menu page during the build); your hours and address; food and interior photos you have rights to use (your own shots from the dining room are ideal; stock photos of another restaurant's food are not usable); your logo and any brand color or font guidelines; and login access to whatever ordering or reservation platform you're on so the integration can be configured and tested before launch.

If you have a specials board, a private dining menu, an events calendar, or a catering inquiry process, those come in too. You don't need to write website copy from scratch — menu descriptions, section introductions, and the about text get drafted from the materials you provide and edited for accuracy. Content-gathering is where timelines usually stretch; the build moves fast once everything is in hand.

See all web design FAQs →

Also building for: catering companies · hotels, inns & B&Bs · contractors & home services · all small businesses