How to Structure a Restaurant Website When Your Menu Changes Every Season

A restaurant website built around a menu that changes every season has to solve a different problem than one built once and left alone: the menu has to be structured content that can be updated in minutes, not a static file or a page-builder layout that breaks every time a course changes. Get that one decision right and the rest of the site, speed, search visibility and the way guests actually read it on a phone, gets meaningfully easier.

This guide walks through why the common approach (a PDF menu, updated occasionally, sitting on top of a generic template) causes most of the problems restaurant owners associate with “our website never really worked,” and what to build instead.

Why a PDF menu is usually the first thing to fix

A PDF menu answers the wrong question. It answers “can a guest see the menu,” which almost any format can do, instead of “can a search engine index this menu, and can a guest read it comfortably on the device they are most likely using.” Both of those matter more than they first appear.

What mobile-first indexing actually means for your menu

Google’s own guidance on mobile-first indexing states plainly: “Make sure that your mobile site contains the same content as your desktop site,” and that only the content shown on the version Google crawls is used for indexing. A PDF embedded in an <iframe> or linked as a download does not behave like normal page content on a phone: it often requires pinching and zooming, and depending on how it is embedded, it may not be treated as part of the page’s actual text content in the first place.

The practical result is that a menu built as a PDF is frequently invisible to exactly the kind of search a restaurant most wants to win: “[cuisine] restaurant near me,” “tasting menu tonight,” or a guest searching for a specific dish by name after seeing a friend’s photo of it. If the words describing your food are never rendered as real, crawlable text on a real page, none of that is searchable.

The mobile reading problem is separate from the indexing problem

Even setting search engines aside, a PDF is a worse reading experience on a phone than a properly typeset webpage. It was originally designed to preserve a fixed print layout, not to reflow for a six-inch screen. A guest deciding whether to book a table, often standing outside deciding where to eat, or scrolling on a couch, is the least likely person to want to pinch and zoom through a document. A structured webpage, by contrast, can use a type scale and line length designed specifically for that screen, the same way a well-set page in a magazine differs from a photocopy of the same page shrunk to fit.

Structured menu content, not a PDF and not a page-builder block

The fix is not “make a nicer PDF.” It is building the menu as structured content: real HTML text, organized into courses or sections, that a template renders consistently every time you update it.

What schema.org’s Restaurant type is built to describe

Schema.org defines a Restaurant type in its structured data vocabulary, and one of its properties, hasMenu, is described as accepting “the actual menu as a structured representation, as text, or a URL of the menu.” That distinction matters: schema.org’s own vocabulary treats a structured, machine-readable menu as a first-class option, separate from and preferable to just linking out to a URL of a menu document. Building your menu this way is not an exotic technical choice; it is closer to how the underlying standard expects a menu to be represented in the first place.

Why this makes updates faster, not slower

A structured menu is a template with content slots: a course name, a description, maybe a price. Changing a dish means editing text inside an existing slot. It does not require re-laying out a whole page, re-exporting a PDF, or touching anything outside the specific course that changed. A full seasonal changeover, in this structure, is still just editing several slots at once, not rebuilding the page.

This is also what makes an archive of past menus realistic to keep. Because each version is just structured content rather than a one-off file, storing the previous season’s menu alongside the current one is a matter of not deleting the old record, rather than a separate project.

Typesetting the menu for reading, not only for indexing

Structuring a menu as real text solves the indexing problem, but it does not automatically solve the reading problem. A menu set in the wrong type size, with lines too long to scan or too little space between courses, can be perfectly indexable and still feel like a chore to read on a phone. Typesetting is the part of this that most restaurant website builds skip entirely, and it is where a lot of the perceived quality of a site actually comes from.

Line length and rhythm matter more than font choice

A course description that runs the full width of a phone screen is harder to read than the same words broken into a shorter measure, the same reason a newspaper column is narrow rather than running edge to edge. Consistent vertical rhythm between courses, the same amount of breathing room after every dish rather than a cramped list that suddenly gets airy for no reason, is what makes a long tasting menu feel considered rather than dumped onto the page. None of this requires an unusual typeface. It requires deciding on a type scale and a spacing system once, and applying it consistently to every course, every time the menu changes.

Why this is a structural decision, not a styling afterthought

A page built from structured content, rather than a one-off image or PDF, is what makes consistent typesetting realistic to maintain. If every menu update starts from a template with the type scale already built in, the fifteenth seasonal changeover reads exactly as carefully set as the first one. If every update starts from scratch in a document editor, spacing and hierarchy drift a little more with each revision, which is usually why an older restaurant site feels visibly less put-together than one that just launched, even when nobody changed the “design.”

Speed: why a fast menu page is not optional

Web.dev’s Core Web Vitals documentation sets out three specific thresholds, measured at the 75th percentile of real page loads, split by mobile and desktop: Largest Contentful Paint (LCP) should occur within 2.5 seconds, Interaction to Next Paint (INP) should be 200 milliseconds or less, and Cumulative Layout Shift (CLS) should stay at 0.1 or less. Google’s Search Central documentation states that meeting these thresholds aligns with what its core ranking systems reward, which is a meaningfully different claim than “speed is everything,” but a real one worth taking seriously.

Where the weight usually comes from

The HTTP Archive’s 2025 Web Almanac found that the median home page in 2025 weighed 2,862 KB on desktop and 2,559 KB on mobile, and that images made up the single largest share of that weight on both: 1,058 KB on the median desktop home page and 911 KB on mobile. For a restaurant site, that number tracks with what actually slows a menu page down in practice: large, unoptimized photography of dishes, often multiple full-resolution images stacked on a single page, loaded before anything the guest actually needs to read.

None of this means photography does not matter. It means the images need to be sized, compressed and lazy-loaded deliberately, and that the menu text itself, the part a guest is actually deciding from, should never be blocked behind waiting for every photo on the page to load first.

Local search basics for a single-location restaurant

Most restaurants are not competing nationally; they are competing for guests within a specific radius who are deciding where to eat tonight or this weekend. Google’s own guidance for local ranking names three factors: relevance (how well a listing matches the search), distance (how far the searcher is from the location, or from the location specified in the search), and prominence (how well known the business is, based on information Google has). It gives five concrete recommendations: verify the business, keep hours and information current, respond to reviews, and add photos and videos. It also states directly: “There’s no way to request or pay for a better local ranking on Google.”

That last point is worth sitting with. There is no shortcut that substitutes for the boring, correct fundamentals: the same name, address and phone number listed identically everywhere your restaurant appears online, hours that reflect a holiday closure the same day it is decided rather than a month later, and a website that actually contains the specific dishes and cuisine terms a local guest might search for, rather than only your restaurant’s name.

The questions a menu page should answer before the phone rings

A surprising share of what front-of-house staff field by phone every evening is information the website could have answered on its own, if the menu page and the pages around it were structured to say so plainly. This is worth separating clearly from anything resembling food safety, allergen or nutrition advice, which is a conversation between the guest and the kitchen, not something a website should attempt to answer on a kitchen’s behalf.

What the website can say, and what it should leave to a phone call

The website can state, in plain text near the menu, that dietary accommodations exist and how to request them: “Let your server know about any dietary needs when you arrive, or call ahead and we will do our best to accommodate you.” That is a scheduling and hospitality statement, not a safety claim, and it answers the guest’s real question, “can I even ask about this,” without the site attempting to list specific ingredients, cross-contact risk or nutritional information, which belongs with the kitchen and the printed or spoken menu in the room, not with a webpage.

The other questions worth answering directly

Beyond dietary accommodation, the most common pre-visit questions are usually about dress code, whether a reservation is required or walk-ins are welcome, whether there is parking or validated parking nearby, and whether the space can hold a private party. None of these require a food professional to answer, and all of them are exactly the kind of specific, factual content search engines reward and guests actually search for. A restaurant that answers them clearly on its own site fields fewer repetitive calls and gives search engines more real, specific text to index around the restaurant’s name.

How often should a seasonal menu actually change on the website?

There is no single correct cadence, and no authoritative source states one, because the honest answer depends entirely on the kitchen. A restaurant running a genuinely seasonal, produce-driven tasting menu might realistically change several courses every few weeks as ingredients shift. A restaurant with a more stable a la carte menu might do a real seasonal refresh three or four times a year, with small adjustments in between.

The website’s job is not to dictate that cadence. Its job is to make whichever cadence the kitchen actually runs on cheap and fast to reflect online, so the gap between what is on the pass and what is on the page stays as close to zero as possible.

Approach	PDF or static-image menu	Structured content menu
Updating one dish	Re-open source file, re-export, re-upload	Edit the text in that course’s slot
A full seasonal changeover	Redesign or rebuild the file from scratch	Edit each slot; layout stays intact
Readable on a phone	Often requires pinching and zooming	Reflows to the screen automatically
Indexable by search engines	Frequently invisible as text content	Indexed as normal page content
Keeping an archive of past menus	Requires manually saving old files somewhere	Previous version simply is not deleted

A short procedure for auditing your own menu page

If you want to check where your current site stands before changing anything, this is the order that surfaces the biggest issues fastest:

1. Open your menu page on a phone, not a laptop, and try to read it the way a guest actually would.
2. Check whether the menu text is selectable. If you cannot highlight and copy a dish name directly off the page, it is very likely an image or a PDF rather than real text.
3. Look at how long the page takes to feel usable, particularly on a mobile connection, not just how long the top image takes to appear.
4. Search your own restaurant name plus a specific dish you currently serve, and see whether that dish shows up anywhere in the search result’s description.
5. Check your business listing for whether the name, address, phone number and hours match exactly what is on your website, since a mismatch undermines the relevance and prominence factors above.

Most of what surfaces in that five-minute audit points back to the same root cause: a menu that was built once, as a document, rather than as structured content designed to be updated as often as the kitchen actually changes.

Where this fits into a full site build

None of the above is a reason to rebuild everything at once. It is a reason to be deliberate about the one page that carries the most weight on a restaurant’s website: the menu. A typeset menu page built as structured content solves the indexing and mobile-reading problems directly, a fast, custom-coded build solves the speed problem, and consistent local business information solves most of what local search actually rewards.

If your kitchen runs a genuinely seasonal, changing menu, the seasonal kitchens page covers the specific workflow that keeps a fast-changing menu current without turning every changeover into a small project. If the format is closer to a fixed, sequential tasting menu, the tasting menu restaurants page covers how that sequence is set to read correctly online.

Seeing the difference in practice is faster than reading about it. A live demo walks through a structured menu build for a kitchen close to yours, on your own screen, so you can judge the actual reading experience rather than imagining it from a description.