Restaurant website design for people deciding on the sidewalk

The workflow starts with who changes the menu. We want a named person, often the chef or a manager, and a format they will actually open on a Tuesday. A structured menu on the site beats a photo of last spring's PDF, because a sold-out dish and a price change should not wait on a designer. If the only reliable source is a PDF they already update, we can show that file and label the date. A stale specials block is worse than no specials block. If nobody will edit specials, we leave them off.

Hours have to match the door and the Google Business Profile. Holiday hours are a field you can change, not a blog post from last November. If you are closed Monday, the site says closed Monday. If the kitchen stops seating at nine, the page can say that in one line so a person does not arrive for a table you will not start.

Reservations are a link to the system you already use, or a plain statement that you are walk-in only. We do not invent a booking button. Online ordering is the same kind of link: the ordering product you already pay for, opening in that product. We do not rebuild a point of sale, a kitchen screen, or a delivery fleet inside the website. If you do not offer ordering, the site does not grow a cart.

• A menu a named person at the restaurant can update
• Hours that match the door, including days you are closed
• A reservation link, or a clear walk-in note
• An ordering link only when online ordering is real
• Address, map, and a plain note about parking

The layout is for a phone first. The person is on the sidewalk, in a car at the light, or in a group chat trying to pick a place. The first screen should show the name, the hours today, and a way forward: call, menu, reserve, or order. Those actions are thumb-sized. A desktop composition that looks elegant and hides the hours below a full-bleed video fails the actual visit.

We test it that way. A phone, outside or on a slow connection, with the menu text readable without pinching. The address is a map link. Parking is one or two sentences you confirm: the lot behind the building, street parking, a garage two blocks off. If parking is difficult, say so. People would rather know before they drive. Private dining or buyouts get a page only when you host them and can say the group size you can take.

The phone number is for the host stand or the line you want guests to use, and it is a tap target. If you would rather they not call during service, the page can say reserve online and keep the number for large parties. The site should not advertise a call you do not want, and it should not hide a call you do.

• Today hours and the next action visible without scrolling far
• Menu text that can be read on a phone without a zoom fight
• Call, reserve, and order as separate actions, each only if true
• Parking and location written in a sentence a local would recognize
• A check on a slow phone connection before launch

If you have photos of this room, this plating, and this staff, those are the photos. We will help place them, crop them for the phone, and keep the files light enough that the menu still appears. We do not invent photos. We do not buy a stock bowl of pasta and present it as tonight's service. Guests who arrive to a different room notice, and they say so.

If the photography is thin, the site can launch with the real pictures you have, even if that is the storefront and two dishes. An empty gallery is acceptable. A fictional gallery is not. We will tell you what is worth shooting later: the entrance, a table, a dish you are proud of, the bar if you have one. That is a shot list, not a promise that we fabricate the images in the meantime.

Captions stay factual. The dish name you use on the menu, the room, the patio if it is your patio. We do not caption a photo with a superlative you would not say to a guest at the door. Credit the photographer when you have one. If a photo includes guests, we ask before it goes on a public page.

Fake reviews stay off the site. We will not write diner quotes, invent a regular's name, or add a star widget that is not tied to reviews you actually have. If you want to point at a public review profile, the link can do that. The quotes themselves have to be real.

Doorway pages stay off the site. A restaurant has a door. Publishing "best brunch in" every nearby neighborhood, with the same paragraph and a swapped name, does not create a second dining room. One location page, with honest notes about the area around the door, is the page. A second location gets its own hours, menu if it differs, and parking note because it is a different room.

Guaranteed rankings stay off the site. We will not promise the map pack for "restaurant near me" or a standing above the other kitchens on the street. Clear hours, a current menu, and a fast phone page are the job. A rank is not a feature we install. We also will not promise covers, a full book, or a wait time the host stand cannot keep.

Example, not a case study, and not a client result. Picture a 48-seat room that serves dinner and is closed Monday. The chef will edit a simple menu list. The site uses that list, not a picture of an old PDF. Reservations go out through the product they already pay for. Online ordering goes out through the separate ordering product they already pay for. We do not build a new point of sale. The parking note says the small lot behind the building fills by six, then it is street parking.

They have eight photos of the room and none of the food that they are willing to use. The site launches with those eight. We do not fill the gap with stock dishes. A private-event page is skipped because they do not take buyouts. The phone is the host stand, and the mobile header shows tonight's hours plus Reserve.

That is the workflow: name the editor, match the hours, link the systems you have, describe parking, and use only this restaurant's pictures. It is an example of the scope. It is not a claim about reservations, covers, or search position.