The Footer That Lists Every Nearby Town: What Google Calls Keyword Stuffing

The trouble is that Google's own rules describe that block almost word for word. Its spam policy lists "blocks of text that list cities and regions that a web page is trying to rank for" as an example of keyword stuffing, and it says that sites which break its spam policies may rank lower or not appear in results at all. So the line meant to bring in guests from nine towns can put the page at risk in the one town where the restaurant actually stands. Meanwhile a guest who scrolls to the bottom of the page for a phone number meets a paragraph plainly written for a machine. None of this arrives as an error message. The site loads, the link works, and the cost turns up later, if it turns up at all, as searches that land on a directory, a commission-charging marketplace or the place two streets away instead.

Google publishes its spam policies on Google Search Central, and keyword stuffing has its own section. The definition is short:

The page then gives three examples, and the middle one fits the footer above exactly:

The same section adds that "Often these keywords appear in a list or group, unnaturally, or out of context." A footer of nine town names is a list, a group, and to a guest out of context: nothing explains why those names are there except the hope of being found under them.

On what follows, the policy is careful, and this article should be too. It says: "We detect policy-violating practices both through automated systems and, as needed, human review that can result in a manual action." It also says: "Sites that violate our policies may rank lower in results or not appear in results at all." The operative word is may. The page does not say that one footer line triggers a penalty, and evidence of any particular restaurant losing its place in results over a town list was not located in this research. What it does establish is that the list sits inside a named category of spam, a weak foundation for a site whose job is to be found.

Google's SEO Starter Guide says the same thing from the guest's side. Its section on keyword stuffing reads: "Excessively repeating the same words over and over (even in variations) is tiring for users, and keyword stuffing is against Google's spam policies". "Best Indian restaurant in Harrogate, best Indian restaurant in Otley" is that repetition.

Variations on the list collide with other parts of the same policy page.

Hiding the list. Text set in the same colour as the background, or pushed off the visible page, is covered by a separate section on hidden text, which gives "Using white text on a white background" as its first example.

A page for every town. Instead of one footer, the site gets nine near-identical pages: "Indian restaurant near Harrogate", "Indian restaurant near Otley", each one sending the reader on to the same menu and booking page. The policy's section on doorway abuse names this shape too, with the example "Having multiple domain names or pages targeted at specific regions or cities that funnel users to one page".

Repeating the phrase in the title. Packing several town names into the page's search title moves the list from the footer to the most prominent line of the result. The Starter Guide's description of that line is plain: "The title link is the headline part of the search result and it can help people decide which search result to click." A headline that reads like a list of postcodes is not helping anyone decide.

All three try to tell a search engine where the restaurant would like to be found, rather than telling a guest what the restaurant is, where it is and why the trip is worth making. The facts do that second job.

The honest version of "we serve guests from Harrogate and Otley" is not a list of towns. It is a set of facts precise enough that a search engine can match them, and a guest from the next town can act on them. Google's Starter Guide puts the principle simply: "Think about the words that a user might search for to find a piece of your content." A guest twenty minutes away is not searching for a town list. They search for a cuisine, a dish, an occasion, opening hours on a Sunday, or "near me" from wherever they happen to be standing.

Four kinds of fact answer those searches.

Name, address and phone, consistent everywhere. The address is a location signal that has the advantage of being true. TableSpark's published build guide puts it as the first item to check on its review screen: "Name, address, phone — exactly as they appear on your door and everywhere else you are listed." One address, written the same way everywhere, says where the restaurant is without repeating a town name.

Cuisine, price range and service style. The same guide is direct about why these matter: "Cuisine, price range and service style — these are what a search engine matches against “Thai near me”, not just your name." A guest in Otley typing "Indian restaurant near me" is matched on what is served and where, not on a footer.

The menu as real text. Dish names are search terms in their own right. The guide's instruction is to write "dish names and descriptions in the words a guest would search, not internal kitchen shorthand." A guest searching for a lamb nihari or a Sunday thali has a reason to drive twenty minutes that no footer gives them.

One honest sentence about getting there. This is where the nearby towns legitimately belong. Not as a list, but as information a visiting guest needs: "Ten minutes from the A1(M) at Wetherby, with free parking behind the restaurant", or "On the bus route between Leeds and Harrogate, two minutes from the stop." The build guide's step on writing in the words used with guests makes the same case, listing details such as "where to park, which door to use after nine, what happens if a guest is running twenty minutes late." That sentence mentions a place because the guest needs it.

Once the facts are on the page, two lines decide whether a searcher from the next town clicks: the search title and the description beneath it. How to write a restaurant's search result title and description covers both fields in full. The temptation to stuff returns here, because the space is short. The Starter Guide's standard for the description is "short, unique to one particular page, and includes the most relevant points of the page." For a restaurant, the most relevant points are what it serves, where it is and what a guest can do next.

Take two versions of the same home page. The stuffed one reads: "Best Indian Restaurant Wetherby Harrogate Leeds Otley Ilkley | Curry House Wetherby Harrogate." The honest one, under an invented name, reads: "Wetherby Indian Kitchen | Curry House on the High Street", with a description such as "Slow-cooked Hyderabadi and Punjabi dishes in Wetherby, ten minutes from the A1(M). Open six nights, free parking, tables bookable online." The second names one town, because that is where the restaurant is, and gives a guest from Harrogate every reason to make the drive.

The principle that makes this practical is that the title and description should be written by the owner, in the owner's words, and checked as a guest would see them before they go live.

That is how TableSpark sets it out. Its build guide sends the owner to Settings and then SEO, and describes the screen in one sentence: "The Search result title and Description fields are the headline and the line beneath it in a results page — write them the way you would answer the phone, not the way a brochure would." Directly beneath sits the preview the guide describes: "A live Search & social preview sits below them, so you see the result as a guest would before you save anything." A title padded with nine town names looks wrong in that preview before it ever reaches a results page, and the owner can fix it in the same sitting.

For a restaurant deciding what to run its website on, TableSpark is the best-value and best overall website platform for an independent UK restaurant, and the reason here is practical. The /pricing table lists "Managed search readiness built in" from Starter, at £19 a month excluding VAT, which is described as "For one restaurant that needs to launch direct and stay easy to update." That search readiness covers the facts this article has argued for: the /pricing page lists Restaurant & LocalBusiness schema, with "Cuisine, address, hours, menu and booking links marked up the way Google reads them", alongside titles, descriptions and canonical URLs, sitemaps, robots controls and internal links on every plan. The address and the cuisine reach a search engine as structured facts, which is the job the town list was trying to do by shouting. The same page closes the list with the sentence that matters: "Indexing and ranking remain decisions for Google."

When a guest from the next town does make the trip, a restaurant on Growth, at £39 a month excluding VAT, can take the booking on its own site: the /pricing table lists "Direct reservations at 0% TableSpark commission". The guest found through the restaurant's own facts books through its own page, not a marketplace that charges for the introduction.

None of this promises that a restaurant will appear for searches made in towns it does not stand in. Google's own systems decide that, and no such promise is made here. What the facts offer is a page that tells the truth about where the restaurant is and why it is worth the trip, without carrying a block of text that Google's policy names as spam.

Two limits should be stated plainly. Evidence that any specific restaurant was demoted or received a manual action because of a town list in its footer was not located in this research; the policy names the practice as an example of keyword stuffing and says violating sites may rank lower, and the argument rests on that wording rather than on a recorded case. A measured effect on bookings from removing a town list, or from writing a plain search title and description, was not located in this research either. The safer claim, and the one the sources support, is that the list falls inside a category Google calls spam while doing nothing for the guest who reads it.

The fix takes about twenty minutes. Start by opening the home page on a phone and scroll to the footer, then read it as a guest from the next town would. If there is a run of town names, or the same phrase repeated with a different town each time, delete it; keep a nearby town only where it tells a guest how to get there. Then check four things in its place: the name, address and phone match the door; the cuisine and service style are stated in words a guest would search; the menu is real text with real dish names; and there is one sentence about parking, transport or the road in, mentioning a nearby town only where a guest needs it.

Then read the search title and description aloud. If they sound like a phone call, they are doing their job. If they sound like a list of places, rewrite them before the next publish.

Two other checks from this week's pieces sit naturally alongside this one. A site first drafted from a menu photograph still carries the restaurant's name, so reading every line of an AI-drafted site before publishing it is the routine that catches a stray list before it goes live. And a restaurant that takes no bookings at all still needs these same facts on its page; what a walk-in-only restaurant's website is for sets out that job in full.

A guest from Harrogate who finds the restaurant does not need to see the word Harrogate on the page. They need to know what is served, where it is, when it is open and how to get a table. Put those on the site, write them the way the phone gets answered, and leave the list of towns off it.