Multi-location SEO: fewer location pages, better location data

The number we usually end at: We have recommended deleting location pages more often than adding them. On the last portfolio we took through this, 210 pages became 46, and organic sessions to the location layer rose over the following two quarters because the surviving pages stopped competing with each other and with the locator. A page whose only difference from forty others is the city name in the heading is not a location page. It is a template with a variable, and Google reads it that way. How a location page earns its URL: It has to say something only that site can say. Staff who work there and are named. Services or stock that genuinely differ from the next branch. A phone number that rings at that address. Hours that vary, including the seasonal ones. Parking and public transport specifics, which is the section customers actually read and which no template can generate. If a location cannot fill those fields, it belongs as an entry in the locator with a profile behind it, not as an indexable page. That decision gets made per location, in front of you, with the criteria written down so your team can apply it to next year's openings without us. The Dutch layer: Most footprints here get the geography wrong. Pages are built for gemeenten because that is how the internal reporting is structured, while people search for the plaats, and in the four big cities for the stadsdeel. Province pages get built because the taxonomy looked tidy and then never receive a query. We set the URL pattern to match how the market searches, keep it stable through renames, and refuse to build a level of the hierarchy that has no demand behind it. Locator and crawl path: A store finder rendered entirely in JavaScript with no anchors is the most common reason a footprint's pages sit unindexed. Every location needs a server-rendered link from a crawlable index, and the index itself needs to be reachable in two clicks from the homepage. We specify that, then check it in the rendered DOM rather than taking the developer's word. One record, four destinations: The operational half matters more than the page half. Your locations belong in one table — in the CMS, the ERP, wherever it already lives — that publishes to the website, Google Business Profile via location groups and the Business Information API, Apple Business Connect and Bing Places. One change, made once, arriving everywhere. Without it, hours drift between channels within a quarter and every subsequent measurement is untrustworthy. Bulk profile edits queue for review, so we sequence them rather than pushing a footprint's worth of changes in one afternoon. Measurement across a footprint: Aggregate rankings hide everything. We report per location against its own catchment and check cannibalisation in Search Console by page, since the visible symptom of a bad location architecture is Google rotating between three of your URLs for the same query and none of them holding. Excluded: City pages for towns where you have no premises. Unique copy written for hundreds of pages, which is the request we decline most often — if the page needs invented paragraphs to justify itself, the decision to build it was wrong. Review generation, outreach, and paid local media. We specify the locator; your developers build it and we review what they ship. Not a fit: Franchise networks where each franchisee controls their own profile and will not grant access. That is a governance problem sitting on top of an SEO problem, and until head office can compel a data standard, this engagement produces recommendations nobody can enforce. We would rather tell you that at the first call than bill for the recommendation.