Cedar & Salt: One Source of Truth for Seven Restaurants
Cedar & Salt operates seven restaurants across two states. A single site hosts a home page, one page per location, a menu page, and a reservations page. Each restaurant's menu is published as a 4 MB PDF that is re-uploaded whenever prices change. Hours are typed directly into each location page's HTML; the site currently says the Harborside location closes at 9 p.m. while its Google Business Profile says 10 p.m., and customers have complained. Online ordering runs in a third-party iframe that fails on iOS 15 Safari because of a cookie restriction. Each location also runs its own Facebook page. One franchisee has asked for a dedicated standalone site per city, arguing it will help local search. Traffic is 78% mobile, and 46% of sessions start on a location page.
1. Should the menus stay as PDFs or move to HTML? Give a recommendation with reasoning tied to the evidence.
Read the worked answer
Recommendation: structured HTML menus, generated from a single data source, with an optional print-quality PDF produced from that same data.
Why the PDF fails here: 78% of traffic is mobile and 46% of sessions begin on a location page, so the menu is a primary destination, not an afterthought. A 4 MB PDF on a phone means a long download, then zooming and panning around a fixed page. It cannot be indexed, so people searching for a specific dish never land on it. If it was exported from a design tool it likely has no tags or reading order, which is an accessibility problem. And the re-upload workflow is why prices drift out of sync across locations.
What replaces it: a menu content type with item name, description, price, dietary tags, and allergens, rendered as clean HTML grouped by section. That gives fast load, real text, search visibility, and easy edits when a price changes - one edit, all views updated.
Trade-off: someone must enter the data rather than drag in a file. A short admin form makes this a fifteen-minute task per menu change, and it eliminates the re-upload cycle entirely.
Keep one PDF for printing and for guests who want it, clearly labelled with file type and size, generated automatically from the same records so it can never contradict the web page.
2. Hours are inconsistent between the site and Google. Propose a data model that prevents this class of error, and name the downstream outputs it should feed.
Read the worked answer
The failure is architectural: hours exist as typed prose in seven separate HTML pages, so there are seven chances to be wrong and no way to know which copy is authoritative. The fix is to store the fact once.
Data model: a Location content type with fields for street address, geocoordinates, phone, timezone, and a structured hours table - one row per weekday with open and close times - plus a separate field for holiday or exception hours with an effective date range. Timezone must be explicit, because the two states may not share one. Add a last-verified date so staleness is visible.
Outputs from that one record:
- The location page hours block.
- The home page and any location listing.
- Schema.org LocalBusiness or Restaurant JSON-LD with openingHoursSpecification, generated from the same fields.
- The Google Business Profile listing, either via API sync or through a weekly reconciliation check against the stored record.
- Any location finder, reservation widget, or third-party directory feed.
Governance: only one role can edit the hours field, and changes trigger a review task for the profile listings. The Harborside discrepancy gets resolved by deciding which source is correct - verified with the store manager - then correcting the record and letting it propagate. Consistency across name, address, and phone is also what local search rewards, so this is an SEO fix as much as a customer-service one.
3. How would you answer the franchisee who wants a separate website per city, arguing it will improve local search?
Read the worked answer
Acknowledge the goal - more local visibility - then challenge the mechanism. Separate domains are not what drives local search performance.
What actually drives it: a well-optimized Google Business Profile per location, consistent name, address, and phone data across the web, genuine local content, reviews, and local citations or links. None of those require a separate domain. A dedicated location page on the main site, with its own address, hours, staff, parking notes, and LocalBusiness structured data, serves the same purpose while inheriting the brand domain's authority.
Costs of seven sites: link equity splits seven ways; each site needs its own hosting, security updates, backups, analytics, and content maintenance; the brand fragments; and inconsistent hours or addresses across seven sites is exactly the problem Cedar & Salt already has, multiplied. Duplicate menu and brand content across seven domains also creates internal competition for the same brand queries.
What to offer instead: a controlled location template the franchisee can edit for local content, plus a shared process for managing Business Profile listings and responding to reviews. If a franchisee wants city-specific landing pages for particular neighbourhoods or events, those can live as subpages of the location page.
Frame it as autonomy within a system: they own their local voice and their profile, not a separate technical estate. Measure success with local pack rankings, direction requests, and calls - the metrics they actually care about.