When to Rebuild Your Restaurant Website: A Decision Framework

The site still works. Hours load, the menu’s there, the reserve button reaches the right form. But you opened it on your phone last week next to a competitor’s, and yours felt three years old next to theirs. Somewhere underneath “it’s fine” a question has been forming: should we just start over? That’s the question worth answering carefully, because the wrong answer costs money in both directions — a rebuild you didn’t need, or a year of leaks you could have stopped for a few hundred dollars.

Here is the answer-first version, so the rest of the page is the proof and not the suspense: the decision is almost never “rebuild or don’t” — it’s “rebuild, patch, or leave it,” and your site’s own numbers already point at one of the three. The honest pattern is that most independent restaurants rebuild 12-24 months later than they should — by which time the rebuild costs more (there’s more to migrate), takes longer (the bookings funnel has decayed further), and the call gets made under stress instead of under planning.

So don’t take that on faith — walk it. What follows is a seven-question diagnostic you run on your own site, top to bottom, no consultant in the loop. Each question hands you a signal, you tally the signals, and the tally lands you on one of three verdicts: rebuild now, patch the leaks for another year, or leave it — the site isn’t the constraint yet. Start with the one number that frames all seven.

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.

Read the number against the two lines and you have a provisional verdict before you touch the other six questions. If you score below 60, then the platform itself is almost certainly the ceiling, and the rest of the diagnostic mostly confirms a rebuild you can already see coming. If you score 80 or above, then you’re in patch territory: a single sub-score is dragging the composite, and one targeted fix usually pulls it back into the green for another year. If you land in the 60-79 band, then hold the verdict open — the next six questions are what decide it, and they’re where the call actually gets earned.

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.

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.

Questions 1 through 4 are the platform’s report card — speed, indexing, the bones. The last three are about whether the site fits how you actually run the room. They’re softer signals, but they’re the ones that quietly decide whether “fine” is really fine.

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.

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

That is all seven questions in front of you. Now collapse them into a single spine. Open each branch, read the verdict its answer earns, and keep a running tally — the count at the bottom is your verdict, not anyone else’s opinion of your site.

Three case threads

The tally lands every site in one of three places. Here is what each verdict looks like once it stops being a score and becomes a plan — three composite patterns, drawn from the kind of site each band describes.

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 number down. The fix is targeted, not structural: add a CDN, recompress every image, repair the menu schema. The score moves to 88, the rebuild defers for two more years, and the spend is a fraction of a full build — on the order of $11K saved against the quote that wasn’t needed.

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.

Strip the three cases down and the real fork is binary: is the platform the ceiling, or isn’t it? Put the two postures side by side and the choice usually names itself.

The 60-79 band is the partial rebuild — the third column that lives between these two. It buys most of the lift for roughly 40% of a full build, with one caveat the chart below makes plain: it caps your ceiling at whatever the underlying platform allows.

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.