Design local pages without creating a duplicate maze.

1. Separate services from places

Use different records for what the business does and where it does it. This keeps a location change from forcing edits across dozens of copied service descriptions.

A staffed office, a travel area and a keyword containing a town name are not the same kind of record. Only the first is necessarily a physical business location. Your content model should preserve that difference.

Service { id, slug, name, scope, exclusions, evidenceIds }
Location { id, slug, publicAddress, hours, access, serviceIds }
CoverageArea { id, name, boundaries, travelTerms, serviceIds }
Evidence { id, type, sourceUrl, owner, verifiedAt }
Page { path, purpose, entityIds, canonicalPath, reviewOwner }

2. Decide whether a new page earns a URL

Write the task the page will solve in one sentence. Then list the unique facts available for that task. If the list is empty, improve an existing page instead.

A real office page can include access instructions, the team based there and available services. A coverage page can explain travel limits and scheduling. A service page can answer scope, suitability, process and next steps.

3. Set one canonical route for each page

Choose HTTPS, a preferred hostname and a trailing-slash policy. Redirect alternate forms consistently. Generate internal links, sitemap entries and canonical tags from the same route definition.

Google treats canonical annotations as signals when selecting a representative URL. They are not a licence to publish unlimited duplicate pages. If a page has no independent purpose, consolidation and a relevant redirect are often clearer than leaving a duplicate URL accessible.

preferred origin: https://example.com
preferred route: /locations/bristol/
canonical: https://example.com/locations/bristol/
sitemap entry: same canonical URL
internal links: /locations/bristol/
old equivalent URL: permanent redirect to the preferred route

4. Choose rendering based on data freshness

Stable service content can be built ahead of time and served as HTML. A browser calculator can hydrate only its interactive controls while its explanation remains readable without JavaScript.

A live availability page has different needs. It may require a server or an API that can retrieve current data without exposing credentials. Do not describe a static export as real-time because it contains a client component.

5. Make the relationships navigable

Link from a service to the places where it is available and from a location to the services actually offered there. Use descriptive labels that tell a reader what they will find.

A hub should help a user choose, not simply expose a long list of keyword pages. Group by task, explain differences and give every detail page a route back. Breadcrumbs are useful when they reflect the actual hierarchy.

6. Test the deployed response

Repeat the checks on the production hostname. A correct local build can still be affected by platform routing, cache rules or a misconfigured redirect. Keep the route inventory in version control so changes are reviewable.

• Fetch each canonical URL directly and confirm a 200 response with the right title and H1.
• Check alternate hostnames and old URLs redirect to the intended destination.
• Request a nonexistent URL and confirm a real 404, not the homepage with a 200 response.
• View source to confirm core content is in the HTML.
• Check robots.txt and sitemap.xml use the production domain.
• Test internal anchors and links after deployment, including from legal pages.
• Assign a review owner for changing facts such as hours and coverage.