When to Rebuild Your Restaurant Website: A Decision Framework

The conversation almost always starts the same way: an operator has two quotes for a rebuild that differ by 3-4x, neither developer has asked what's actually broken, and the operator isn't really asking which quote to take. They're asking whether to rebuild at all. That's the harder question, and almost nobody helps operators answer it.

The honest answer is that most independent restaurants rebuild 12-24 months later than they should — by which time the rebuild costs more (because there's more to migrate), takes longer (because the bookings funnel has gotten worse), and the operator is making the decision under stress instead of under planning.

This is the seven-question diagnostic I run through before recommending a rebuild — or, just as often, recommending against one and pointing at three small changes that buy another year.

Question 1: How does it score on Storefront Health?

Run Storefront Health on your site. The composite scorecard rolls speed, SEO, mobile, schema, GBP, and the Restaurant Audit into one number, 0-100. The chart above maps the bands. The cheap path: a sub-score below the rest is usually one targeted fix away from pulling the composite back into the green.

Question 2: Can your CMS update without breaking the site?

Old CMS installs accumulate technical debt the way ductwork accumulates dust. The test: when's the last time someone tried to update the platform? If the answer is "we don't, because it broke last time," that's a rebuild signal.

Question 3: Does the menu live in HTML?

If your menu is a PDF, an image, or "managed by Wix's menu widget," you're invisible to Google's dish-level queries and to AI search. Switching to a real HTML menu alone is sometimes enough to defer a rebuild — sometimes it requires one.

Question 4: How does the site score on Core Web Vitals?

If LCP is above 4 seconds on mobile, or CLS is above 0.25, you're being penalized in search AND bouncing visitors before the menu loads. Sometimes a CDN + image compression fixes it; sometimes the platform is the problem and only a rebuild will do.

Run Speed Test on the homepage and the busiest interior page. If the homepage is fast but the menu page is slow, the platform isn't the issue — the page is. If both are slow, the platform usually is.

Question 5: Can you ship a small change in under an hour?

Test: try to update the holiday hours on your homepage in the next 60 minutes. If you can't (no access, complex CMS, requires a developer), that's a rebuild signal — not because the technical limitation is fatal, but because the operational burden compounds quietly. Every change you delay is a small leak.

Question 6: Does the brand match the room?

Open your homepage on the phone you carry. Then walk into your dining room. Do they feel like the same place? If not — if the room is warm, considered, intentional, and the site is templated, generic, "we picked the cleanest Squarespace template" — that's a brand-design rebuild signal, separate from the technical ones.

Question 7: What happens to bookings if you do nothing for 18 months?

Look at your monthly booking trend. If it's flat or declining and your site has been the same for 24+ months, doing nothing isn't actually neutral — the gap to your local competitors is widening even when your numbers look stable. The 18-month "do nothing" projection is almost always negative for a stale restaurant site.

Three case threads

Case 1 — Bistro on a 75 score, doesn't rebuild: A six-year-old French bistro scoring 75 on Storefront Health. Mobile speed dragging the score down. We added a CDN, recompressed every image, fixed the menu schema. Score moved to 88; they deferred the rebuild for two more years and saved roughly $11K.

Case 2 — Site below 60, rebuilds: Old front-end, slow on mobile, menu schema malformed, booking funnel hidden. The platform itself is the ceiling. The rebuild here is full custom: real HTML menu, dish-level structured data, the booking funnel cleaned up. Score lands in the high 80s or 90s. Search-driven reservations roughly triple within 90 days because the missing schema starts firing in local-pack queries the site never appeared for before. Payback windows on rebuilds in this range are typically 9-14 months — but the leverage compounds as Google's index updates.

Case 3 — Site at 65-70, partial rebuild: Platform fine, brand tired. Keep the CMS, replace the front-end and the photos at roughly 40% of a full-rebuild cost. Score moves into the low-mid 80s. Bookings tick up — but not as steeply as Case 2. The honest tradeoff worth flagging: a partial rebuild caps your ceiling at whatever the underlying platform allows for schema, speed, and indexing. Sometimes the right call; sometimes worth revisiting in 18 months when the platform's ceiling becomes the next constraint.

Doing nothing isn't neutral. The gap to your local competitors widens every quarter your site doesn't.

Most operators don't rebuild because they can't picture what the rebuilt thing looks like. The framework is a forcing function. Run the questions. The answer almost always already exists.

How to use this framework

Run Storefront Health first. Save the score to your Workshop. Walk through the seven questions, write down the honest answer to each, and look at the pattern. If three or more are pointing at "rebuild," you're past due. If one or two are, you're in fix-the-leak territory — read Five Website Changes That Recover 1% Margin for the targeted-fix approach.

If you want a second pair of eyes on the framework as it applies to your site, write through The Window. I read every one.