Crea un sitio web para tu restaurante que tus invitados puedan usar antes de llamar

Build a mobile-first website for my restaurant. Make the menu, service hours, phone number and table-request route easy to find. Use my supplied facts; ask about missing information instead of inventing it.

RESTAURANT DETAILS
- Name, cuisine, concept and true story: [DETAILS]
- Country, website language, currency and time zone: [DETAILS]
- Address, phone, email and directions link: [DETAILS]
- Opening hours, kitchen service times, last seating and holiday exceptions: [DETAILS, INCLUDING SPLIT OR OVERNIGHT SERVICE]
- Brand colours and feel: [MATCH OUR ACTUAL ROOM]
- Practical information: [VERIFIED ACCESSIBILITY, PARKING, SEATING OPTIONS AND OTHER FACILITIES]
- Existing reservation or ordering service: [OFFICIAL LINK / SUPPORTED WIDGET, OR NONE]
- Who checks table requests and when: [CONTACT AND REAL RESPONSE WINDOW]
- Private events or catering: [ACTUAL OFFER AND CAPACITY, OR OMIT]

EDITABLE MENU
Store menu sections and items as data, editable from a protected owner screen on my phone. Use these supplied items: [NAMES, DESCRIPTIONS, PRICES, PORTION/VARIANT OPTIONS AND MENU AVAILABILITY TIMES]. Record the currency and how taxes or compulsory charges are displayed for my location; ask me if unclear. Support price edits, item order, sold-out status and hiding an item. Reuse the same menu data wherever dishes appear.

Include dietary labels and ingredient/allergen information only from my reviewed data: [SUPPLIED INFORMATION OR MISSING]. Never infer gluten-free, vegan, allergy-safe, kosher or halal claims from a dish name, photo or cuisine. Do not describe an unknown value as allergen-free. Keep missing information flagged for owner review, and give guests a clear way to contact trained staff. Do not invent ingredients or claim that a message box guarantees a special request can be accommodated.

PAGES
1. Home: name, cuisine, location, today's service times and buttons for View Menu, Get Directions and the booking route actually available. Include selected real dishes and a short true story.
2. Menu: readable HTML text, section navigation, prices and reviewed labels. Do not require a PDF download or account to read it. Provide a visible contact route for menu questions.
3. About: write from my facts without inventing awards, history, reviews or team members.
4. Find Us: address, directions link, phone, opening and kitchen hours, holiday exceptions and supplied practical details.
5. Private Events: only if offered; enquiry form with date, party size, contact and a short message. An enquiry does not reserve the venue.

TABLE REQUESTS
If I supplied a reservation provider, use its supported restaurant link/widget with a fallback link. Do not create a second independent inventory or claim calendar synchronization without a verified integration.
Otherwise label the action Request a Table. Collect name, one contact method, date, requested time and party size. Use my seating hours and party-size limits: [RULES]. Save a private Pending request and notify the responsible staff member. Show success only after a successful save: "Request received. Your table is not confirmed yet." Display my supplied response window; do not promise a one-hour response unless I supplied it. Give staff Confirm, Decline and Cancel actions. A staff confirmation must specify date, time, party size and contact details for changes. For urgent requests, show the phone number. Do not take deposits in this first version.

DESIGN AND TRUST
Use my real food and venue photos, or clearly marked upload placeholders. Honest AI edits to my own photos are welcome for crop, exposure or background cleanup; do not invent dishes, alter portions or make food look materially different from what we serve. Use legible type, good contrast, labelled form fields, keyboard access and descriptive alt text. Support RTL if the chosen language requires it.
Create draft privacy and enquiry terms from the actual data and services used, flag missing owner details for review, and keep draft labels off public pages. Do not copy another restaurant's policies or add marketing consent to table requests automatically.

RELIABILITY AND FINDABILITY
Protect menu writes and guest records with server-enforced access rules. Guests must not be able to browse other requests. Validate inputs, limit spam and prevent double submissions. If saving or notifications fail, provide a truthful retry/contact route and a staff-visible error; do not silently lose the request.
Use descriptive page titles and Restaurant structured data that matches visible name, address, menu link and hours. Do not fabricate ratings or promise Google placement.

BEFORE HANDOFF
List setup tasks, missing facts and connected-service costs. Demonstrate a menu edit, a sold-out dish, a holiday/split-shift schedule and a table request from submission through staff confirmation. Test the public site signed out, and check that menu editing and guest records are inaccessible without staff permission.