Nobody books cold. Between deciding to eat out and pressing the button on a reservation, a person runs a small sequence of searches, and each one narrows the field. Most venue websites are built to answer the last search in that sequence and none of the earlier ones, which is why a site can look finished and still generate almost nothing.
The sequence is fairly consistent, so it is worth walking through it in order.
First: the shortlist
The opening query is broad and almost always ties a food type to a place or a moment. Ramen in Carlton. Somewhere for dinner near me. Long lunch spots along the bay. Open now. At this point the person has no venue in mind and is not going to read anything. They are scanning names, photos, star ratings and distance, and they will shortlist perhaps four options in under a minute.
What wins here is presence rather than persuasion. If the venue is not in the local results for its own food type and suburb, it is not in the running. That is a listing problem more than a copy problem, and it is covered separately in why your restaurant does not show in the map pack.
Second: the check
Having shortlisted, the person now opens tabs and compares. The queries get specific: the venue name plus menu, the venue name plus reviews, the venue name plus prices. This is where most shortlisted venues fall out, and usually for boring reasons.
The menu is a PDF that opens sideways on a phone. The menu is a photograph, so nothing on it can be read by a search engine or enlarged by a diner. Prices are absent, so the person assumes expensive and moves on. Photos are of an empty room taken by the previous owner.
A readable menu in plain text, with prices, with dish names spelled the way people actually search them, does more work at this stage than any other page on the site.
Third: the practical questions
This is the stage almost nobody builds for, and it is where the booking is won or lost. The person has half decided and is now looking for a reason to stop worrying. Is there parking. Do they take kids. Is there anything gluten free. Can we bring a cake. Is it BYO. Can they seat nine. Is there a room out the back for a birthday. Do they do a set menu for groups. How loud is it on a Friday.
Each of those is a real search, and each one is a sentence you could put on the site today. A venue that answers them plainly, in text, on pages a search engine can read, gets found for a long tail of low volume searches that convert far better than anything broad. Someone typing private dining room for 12 near Richmond is not browsing. They are booking.
Fourth: the booking
By now the person knows what they want and just wants the friction gone. The number of venues that lose people at this point is remarkable: a booking widget that fails on mobile, a phone number that is not a tap to call link, a contact form with nine fields, an enquiry address nobody checks on a Sunday.
If the site cannot take the booking, the phone number needs to be obvious from every screen. Ours sits in the header on every page for exactly that reason: 0455 100 747.
What this means for the pages you build
One question, one page. The group bookings question gets its own page, not a paragraph buried on the contact page. The function room gets its own page. The set menu gets its own page. That discipline is what stops a small venue site competing against itself for the same search, and it is where our restaurant SEO services tend to begin, because the structure has to be right before anything written on top of it can rank.
It also gives you something to say. Most venue sites are three pages of adjectives. A site that answers real questions has a reason to exist, and the answers age well.
The searches you will never see in your reports
A growing share of this happens in ways that leave no trace in your analytics: a voice query in the car, a question typed into an AI assistant, a group chat where somebody pastes a link. You cannot measure those directly, but they are answered from the same material. Clear text, accurate hours, a real menu, plain answers to plain questions. Venues that write that material get quoted by the assistants. Venues that hide it in a PDF do not.
Where to start
Write down the last twenty questions your staff were asked on the phone. That list is your content plan, in priority order, drawn from real demand rather than a keyword tool. Most of it will be parking, dietary requirements, group sizes and opening hours, which tells you something about how much of the internet a restaurant actually needs.
Then check that each answer lives somewhere a search engine can read it.
Frequently asked questions
Should the menu be a PDF?
No. A PDF is awkward to read on a phone and its contents are far harder for a search engine to use. Put the menu in plain text on the page and keep a PDF only as an optional extra download.
Do prices need to be on the site?
If prices are missing, a share of people assume the higher end and leave. Publishing them removes a reason to hesitate, and it filters out enquiries that were never going to book.
How many pages does a small venue need?
Fewer than most agencies suggest, but more than three. One page for each real question you are asked repeatedly: functions, group bookings, the set menu, parking and access.
Is it worth writing separately for voice search and AI assistants?
No separate writing is needed. Clear text, accurate hours and plain answers to plain questions are what those systems draw on, so the work that helps a person helps them as well.
