Thin Pages on a Cafe Site: Turn Them Into Useful Ones


Short answer: a thin page is not a page with a low word count. It is a page that does not answer any question a real customer would actually bring to it. Some one paragraph pages are genuinely fine. Some five hundred word pages are still thin, because none of those words answer anything.
If you own a cafe site, you almost certainly have a few of these. A location page that lists an address and nothing else. A menu page with three lines typed in a hurry the week you opened. An old coming soon page nobody remembered to finish or remove. The question owners ask me is whether these pages are actively hurting them, and whether the fix is to write more words or just delete the page. The honest answer is that it depends on the page, and this post gives you a way to sort each one into expand, merge, redirect, or delete, without guessing.
What Thin Actually Means
Google's own guidance on creating helpful, reliable, people first content is built around one repeated question: would this page be useful to someone even if search engines did not exist? A page written to have something at a URL, rather than to answer a question, is the kind of page that guidance is describing, whether it is two sentences long or twenty.
That reframes the whole problem for a cafe owner. It is not about hitting a word count. A location page with a full street address, cross streets, parking notes, and a transit line is not thin even if it is short, because it answers every question someone lost outside your shop has. A menu page with fifteen items and zero prep notes, zero seasonal flags, and zero mention of what makes any of them worth ordering can still read as thin, because it never answers the question a hungry, curious visitor brought to the page: what should I get.
Search Console's help documentation on soft 404 errors describes a related but separate problem: pages that return almost nothing, or that look to a crawler like an empty or removed page even though the server says the page exists. A coming soon page that has sat unfinished for a year, or a location page auto generated by a platform template with only a placeholder address, can fall into that same category from a crawler's point of view. It is not the same failure as writing a short, useful page. It is closer to a page that never got made in the first place.
Put those two ideas together and you get a working definition that does not depend on counting words: a thin page is one that fails to answer the specific question its own page type exists to answer. A location page exists to answer where and how to get there. A menu page exists to answer what is available and why. An about page exists to answer who runs this place and why it matters. Judge each page against its own job, not against an arbitrary length.
The Minimum Useful Page
Every page type on a cafe site can be measured against the same short list: who, where, when, what, and one proof detail. Who runs it, or who this page is for. Where it applies, meaning a real address or a real section of the menu. When it is relevant, meaning current hours, current season, or a clear note that something has changed. What the visitor should do or expect. And one proof detail, something specific and real rather than generic, that tells a visitor this page was written by someone who knows the place.
That fifth item, the proof detail, is the one owners skip most often, and it is usually the difference between a page that reads as thin and one that does not. A location page with an address is fine. A location page with the address plus a note that the entrance is around the side facing the parking lot, not the street facing door, is the kind of specific, checkable detail that makes a page feel like it was written by someone who has stood there. It costs one sentence.
This minimum does not mean every page needs to be long. A location page can hit all five items in well under a hundred words and still be a complete, useful page. The goal is not padding. It is making sure nothing on the page is a placeholder standing in for information a real visitor needed and did not get.
It is also worth being honest about what this minimum does not require. It does not require a keyword count, a target length, or a specific number of internal links. Those are the kinds of rules that lead an owner to pad a page with filler sentences that do not answer anything, which is the exact failure this whole approach is trying to avoid.
Three Before and After Outlines
A location page before: name, city, state, and a phone number, nothing else, generated automatically when the site was built and never touched again. After: the same fields, plus the actual street address with cross streets, a one line parking or entrance note, the hours for that specific location if the cafe has more than one, and one proof detail such as a nearby landmark a visitor would recognize from the street.
A menu page before: a bulleted list of drink names with no prices shown and no description, copied from a printed menu board and never updated since. After: the same items organized by category, one short line per item describing what makes it distinct, a note on what is seasonal versus year round, and a single honest line about what the cafe is known for, written by someone who has tasted the menu, not a generic description that could apply to any cafe in the country.
An about page before: a single paragraph stating the cafe opened in a given year and serves great coffee, unchanged since launch. After: who runs the place and why, one real detail about the space or the neighborhood it sits in, a short honest note on what the cafe cares about, whether that is sourcing, roasting, or simply being a good local gathering spot, and a photo or two that show the actual room rather than a stock image.
None of these after versions require padding. Each one answers a real question a visitor would have brought to that specific page type, using the who, where, when, what, and proof detail framework, and each one could be written and published in well under an hour once the missing information is gathered.
What the Census Shows, in Aggregate
Hillcane's own audit work gives some honest, if partial, context here, and it is worth being precise about what it does and does not show. In a census of more than 1,000 shops across six regions, snapshot dated September 15, 2026, 926 of 1,109 shops have a blog with zero posts. A blog with no posts at all is not itself a thin page in the sense this post is describing, but it is a strong signal that a site has very few pages beyond the basics, since a blog is usually where a cafe would otherwise be answering questions its core pages do not cover.
That same audit data shows 56 of 1,109 shops with a blank locations field, meaning the most basic where information for the business was not filled in at all, not thin, simply missing. Separately, the audit notes across those files contain 39 explicit mentions of thin pages, out of 1,109 shops checked as of September 21, 2026, spread across location pages, menu pages, about pages, and a smaller number of blog posts and other page types. That is not a percentage claim about how common thin pages are across the entire population; it reflects what auditors happened to flag in their working notes, and it should be read as a pattern observed, not a rate.
What that pattern does confirm is that thin pages are not a rare or unusual problem specific to one platform or one kind of cafe. They show up across the kinds of pages every cafe site has: the page telling people where you are, the page telling people what you sell, and the page telling people who you are. Those are exactly the three page types this post's before and after outlines cover, because they are the ones worth fixing first.
Deciding Expand, Merge, Redirect, or Delete
Once you know a page is thin, the fix is not automatically to write more. Walk each page through four questions, in order. Does a real visitor land here looking for something specific? If yes, and the page currently fails to answer it, expand the page using the who, where, when, what, and proof detail minimum described above.
If two pages are both trying to answer overlapping questions, for example a general contact page and a separate location page both listing the same address in slightly different words, merge them into one complete page and point the other page's traffic there rather than maintaining two half finished answers to the same question.
If a page no longer applies at all, a coming soon page for something that already opened, an old seasonal menu that has since changed, or a location that closed, redirect it to the page that replaced it rather than leaving it live as a dead end. And if a page never served a real purpose in the first place, an automatically generated placeholder page with nothing on it and nothing a visitor was ever looking for, delete it outright rather than leaving it as clutter for a search engine or a visitor to stumble into.
Run every page on the site through those four questions once, honestly, and you end up with a short, specific list: pages to expand this week, pages to merge and redirect, and pages to simply remove. That list is the actual output of a thin page audit. Nothing about it requires guessing at a word count or padding a page that was never supposed to be long in the first place.
It helps to write the list down as a simple table with four columns: the page, its current problem in one line, the decision, and who owns fixing it. An owner working through this alone can realistically expand or merge two or three pages a week without it becoming a project, since most of the fixes described in the outlines above take less than an hour once the missing details are gathered. The redirect and delete decisions take even less time, since they do not require new writing at all, only a decision and a few minutes of setup on whichever platform the site runs on.
One more thing worth saying plainly: this is not a one time cleanup. New thin pages get created the same way the old ones did, a platform auto generates a location page template when a second address is added, a seasonal menu page gets built quickly during a busy week and never finished, a coming soon page goes up before an opening and gets forgotten after. Building the four question habit once means the next thin page gets caught and fixed in minutes rather than sitting untouched for another year.
Related Reading
More from Hillcane on this topic, plus the pages on the site that sit next to the work.
Frequently Asked Questions
What counts as thin?
A page that does not answer the specific question its own page type exists to answer, regardless of its word count. A short location page with a full address, parking note, and hours can be complete. A longer page padded with generic sentences that never say anything specific about your cafe can still be thin. Judge the page against its job, not against a length target.
Should I delete pages?
Sometimes, but not automatically. Walk each thin page through four options: expand it if a real visitor is looking for something it currently fails to provide, merge it if another page already covers the same ground, redirect it if it no longer applies, such as an old coming soon page, or delete it if it never served a real purpose. Deleting should be the last option, not the first reflex.
Is a short page always thin?
No. A location page can meet the full minimum useful page standard, covering who, where, when, what, and one proof detail, in well under a hundred words. A street address with cross streets plus a note that the entrance faces the parking lot can be complete. Google's guidance on helpful, people first content asks whether a page answers a real visitor's question, and that job, not length, decides whether a page is thin.
How common are thin pages on cafe sites?
Hillcane's audit notes across a census of more than 1,000 shops across six regions, snapshot dated September 15, 2026, contain 39 explicit mentions of thin pages as of September 21, 2026, spanning location, menu, about, and blog pages. That reflects patterns auditors flagged in their working notes, not a measured rate across the full population, so treat it as a signal of where thin pages tend to show up, not a percentage.
What is a minimum useful page?
A page that covers five things: who it is for or who runs it, where it applies, when it is current or relevant, what the visitor should expect or do, and one specific, checkable proof detail that shows the page was written by someone who knows the place. Hitting all five does not require a long page.
Does a blog with zero posts count as a thin page problem?
Not on its own, since an empty blog is a missing content type rather than a single thin page. But it is a useful signal. In Hillcane's census of more than 1,000 shops across six regions, snapshot dated September 15, 2026, 926 of 1,109 shops have a blog with zero posts, which often means the site has very few pages beyond its core basics, the same pages most likely to be thin.
What does Google say about thin content?
Google's guidance on creating helpful, reliable, people first content asks whether a page would be useful to a visitor even if search engines did not exist. Search Console's help documentation on soft 404 errors separately describes pages that appear empty or removed to a crawler despite returning as live. Neither page states a word count minimum; both point at whether the page serves a real visitor.
My menu page is short. Is that a problem?
Only if it fails to answer what a visitor wants to know, which is usually what to order and why. A short list of drink names with no description can read as thin even though it is brief. Adding one honest line per item about what makes it distinct, plus a note on what is seasonal, usually fixes it without making the page long.
What about an old coming soon page?
That is the clearest case for a redirect rather than an expansion. If whatever the page was announcing has already happened, opened, or changed, the page no longer serves the question it was built to answer. Point it to the page that replaced it, such as the finished menu or the now open location page, rather than leaving a dead end live.
Should every location page look identical across a multi location cafe?
No. Reusing the same generic paragraph across every location page is itself a common way thin pages get created, since none of them carries a proof detail specific to that address. Each location page should keep the same five part minimum, who, where, when, what, and one proof detail, but the proof detail and any local notes should be specific to that actual spot.
Work with Hillcane
A location page with only an address is not automatically a problem. A location page that never answers where the entrance actually is, is.
If you want a second set of eyes on which pages to expand, merge, or cut, reach Hillcane at hillcane.co/contact or (256) 384-2449.



Comments