The specials board behind the counter changes every morning. The seasonal menu rotates four times a year. The brunch menu got refreshed two weeks ago and the new dishes are still being calibrated. The website menu hasn't been touched since March 2024.

This is the standard pattern in Australian cafes and it's a quiet structural problem. The customer Googling "best brunch in Brunswick" sees outdated dishes. The supplier looking at your About page sees the original launch story. The food press journalist writing about your neighbourhood sees a menu from 14 months ago and assumes you've stopped trying. Meanwhile, the actual cafe — the menu, the specials, the seasonal updates — is moving constantly and not making it onto the website.

The opinion to lead with: the menu page on a cafe website should update as fast as the kitchen does, and that's an engineering problem most cafes solve wrong. They either (a) give the floor staff CMS access and live with the typos and broken images, or (b) leave the menu page static and let it rot. Both approaches are bad. There's a third one that works for most cafes, and it's worth understanding because it's the single most underrated cafe website investment of the last five years.

Why the menu rot happens

Cafe menus rot for predictable reasons.

The website was built by an agency or a freelancer 18 months ago. The contract is finished. Updates require an email, which requires checking the agency is still in business, which requires getting a quote, which gets put off. The cafe owner mentally writes off the website as "fine".

The menu is on a PDF. Updating the PDF means opening the source file (usually a Word document or a Canva design), making the change, exporting to PDF, uploading the new PDF to the website, and checking the link still works. This takes 25 minutes. Nobody has 25 minutes during a service week, and once you've decided not to do it this week, you've decided not to do it next week either.

The menu is on the website CMS but the CMS is hostile. The cafe owner logs in, looks at the menu page, gets confused by the block layout, edits the wrong text, accidentally deletes a photo, and doesn't know how to undo. Then they decide to wait for the agency to update it. The wait extends.

The result, across the Melbourne and Sydney cafes we've audited, is a median menu staleness of 9 months. The cafe that's iterating their menu every fortnight has a website showing dishes that aren't on the menu anymore.

The cost of the staleness

The customer impact of an outdated menu is real but uneven.

A customer who's already a regular doesn't care. They know what you serve. They don't read the website. The menu staleness has no impact on them.

A customer researching online for a first visit is where it shows up. They're choosing between three cafes. They want the avocado dish on the menu they saw on Instagram. Your website shows the dish from 2024. They check the cafe Instagram for confirmation. They can't find it. They go to the cafe whose website actually shows it.

The delivery customer is the harshest case. They're ordering through UberEats. The website menu they checked at home doesn't match the UberEats menu (which is updated more often because the delivery channel forces it). They wonder which is right. They lose confidence in the cafe and order elsewhere.

The supplier and press impact is the long-term one. A coffee roaster considering a wholesale partnership looks at the website to see what the cafe is currently doing. An outdated menu reads as a cafe that's not actively iterating. The roaster goes to the next conversation. Same with a food journalist scouting for a piece — the cafes with current websites get included.

The aggregate financial cost is hard to quantify cleanly, but on a $1.2M cafe with meaningful first-visit and delivery channels, somewhere in the range of $20,000–$45,000 in lost annual revenue from menu staleness alone is realistic.

The four approaches to keeping the menu current

Here's how cafes actually handle menu updates, in order of badness.

Approach 1: Static PDF, updated when the agency is paid

Worst. The PDF is uploaded once and lives forever. Updates require a paid intervention. The cafe owner avoids them.

Approach 2: Static HTML page, updated when the agency is paid

Slightly better — the menu is in HTML so it's at least searchable by Google. But the update process is the same. Stale within months.

Approach 3: Cafe owner edits the website CMS directly

Worse than it looks. The cafe owner can update the menu — and does, occasionally — but the editing experience is fiddly, the photos drift in size and quality, and the layout breaks when paragraphs get longer than the original. The page degrades visually over time even as the content stays current. Many cafes start here and end up at Approach 1 or 2 after the page breaks in a way the owner can't fix.

Approach 4: Menu lives in a database the floor staff can update from a phone

This is the approach that works. The menu is structured data — dish name, description, price, dietary tags, optional photo — in a content management system designed for it. The floor staff (or the owner) updates the database from a phone app, the website re-renders automatically. The visual layout is locked, so updates can't break the design. The database is the source of truth.

This is what the cafes whose menus stay current actually do. The mechanism is invisible to the customer — they just see a menu page that's accurate. But the structural choice underneath is different from the other three approaches.

What "Approach 4" actually looks like technically

There are a few ways to build this. The right one for a specific cafe depends on the technical stack the rest of the website is on.

Option A: Notion as the source of truth

The simplest setup. The menu lives in a Notion database. Each dish is a row with structured fields. The website pulls from Notion via the Notion API and renders the menu page server-side. Updates to the Notion database appear on the site within minutes.

Pros: Notion is free or cheap. The interface is familiar — the cafe staff probably already use Notion for shift notes. The mobile app is decent.

Cons: Notion's API has rate limits and occasional slow responses. The site has to handle caching properly. It's not ideal at scale beyond about 50–80 menu items.

Option B: Headless CMS (Sanity, Payload, Hygraph)

The professional setup. The menu lives in a purpose-built headless CMS like Sanity, Payload, or Hygraph. The cafe staff have a dedicated editor — a web app that's optimised specifically for menu editing. Add a dish, set the price, drag the photo in, add the dietary tags, save. The website re-renders.

Pros: The editing experience is built for this. Fields are validated (you can't accidentally publish a $0 dish). Image uploads handle resizing and formatting automatically. The workflow scales to large menus.

Cons: Setup cost is higher — $5,000–$12,000 for the CMS configuration plus the menu page build. Ongoing cost is $0–$200/month depending on the CMS choice (Payload self-hosted is free; Sanity has paid tiers).

For most established cafes, this is the right answer.

Option C: Square Catalog with a custom display layer

If the cafe is already using Square for the POS, the menu items already exist in Square's Catalog API. A custom website can pull from there and display the menu without anyone manually maintaining a separate menu database.

Pros: One source of truth (Square). Updates the POS staff make automatically appear on the website. No additional admin work.

Cons: Square's catalog isn't designed for marketing display. Dish descriptions are usually thin. Photos may not exist. The website has to supplement the data with marketing fields (longer descriptions, hero photos) somewhere else, which partly defeats the "one source of truth" benefit.

For cafes where the POS menu and website menu are tightly aligned (lunch counters, takeaway-heavy operations), this works well. For cafes where the website needs to communicate more than the POS does (full-service restaurants, brunch destinations), Option B is usually better.

Option D: Google Sheets as the source

The shoestring version. The menu lives in a Google Sheet. The website reads from the Sheets API and renders the menu. Updates to the Sheet appear on the site.

Pros: Free. The cafe staff already know Google Sheets. The mobile interface is workable.

Cons: Google Sheets isn't a CMS — there's no validation, no image handling, no version history that anyone can use. It works for tiny menus and breaks at any scale. Useful as a quick fix for specials only.

The specials problem specifically

Daily specials are a separate problem from the main menu. The specials change every morning. The cafe staff don't have time to update a CMS at 6:30 AM.

The pattern that works:

The main menu page renders from the menu database (Approach 4, however it's set up)
A "Today's Specials" section on the homepage pulls from a separate, simpler source — usually a Google Sheet or a short text field in the CMS
The kitchen staff or front-of-house manager updates the specials sheet during morning setup, taking 90 seconds
The website pulls fresh specials on each page load (or via short-cache)

This decouples the specials from the menu architecturally. The full menu changes occasionally and uses the proper CMS. The specials change daily and use the lightweight tool. The website always reflects both.

For cafes that want to take this further, the specials can integrate with the Instagram bio — a short URL that always points to today's specials, refreshing automatically — and with the Google Business Profile posts, where today's specials become a public post that shows up in Google Search and Maps.

The build cost

For an existing cafe that already has a Squarespace or WordPress site, the migration to a menu-database-driven setup is a project, not a tweak. The cost depends on which approach.

Approach 4A (Notion source): $3,500–$6,000
Approach 4B (headless CMS): $6,000–$14,000 depending on menu complexity
Approach 4C (Square Catalog): $4,500–$9,000
Approach 4D (Google Sheets, specials only): $1,500–$3,000 for the specials layer on top of an existing site

These prices assume the rest of the website is staying as-is. If the cafe is rebuilding anyway, the menu architecture is a small addition to the larger project cost.

The payback is the staleness gap closing. If the website was costing $30,000/year in lost first-visit and delivery revenue from being out of date, even a $10,000 investment pays back in five months.

The honest bottom line

Cafe menus are dynamic. Cafe websites are usually static. The mismatch is structural — most cafe websites are built like brochures and menus aren't brochures. The cafes whose menus stay current have made an architectural choice that brochure-builders haven't.

The cost of fixing this is moderate. The cost of not fixing it is invisible — the customers you didn't get, the press coverage you missed, the delivery confusion that hurt your rating. Invisible costs are the worst kind because they're easy to ignore until you notice your numbers are off.

If your cafe website is showing dishes from a previous menu, it's time to fix it. The fix isn't a redesign — it's a small architectural change that lets the menu page become a real living surface.

If you'd like an honest look at what the right menu architecture is for your specific cafe operation, book a free audit. We'll review the current setup, look at the menu update cadence, and tell you what the realistic build scope would be.

How to Build a Cafe Menu That Updates Daily (2026)