Two locations, one codebase, and a gate that remembers

A barbershop with two locations has a navigation problem before it has a marketing problem. Most multi-location sites solve it with a location picker in the header and then serve everyone the same page, which leaves the visitor to work out which hours and which booking link apply to them.

The gate

First time visitors get a location gate. They pick a shop, land on that shop's routes, and the choice is stored in a cookie for 180 days, so returning visitors go straight there. Anyone who needs to switch can, through a link in the footer or by adding a query parameter to the home page. The gate is a single decision at the start rather than a question the visitor has to keep answering.

One file drives the site

The build's organizing constraint is that a single locations module is the source of truth. Routes, navigation, the sitemap, the JSON-LD schema, booking links, the gate screen, and the sticky call to action are all generated from it.

Adding a third shop is appending one entry to an array. Nothing else changes. That matters for a business that expects to open more locations, because the alternative is a rebuild every time, or worse, six places where the new address has to be pasted and five of them get found later.

Local schema per shop

Each location emits its own structured data rather than the business emitting one block for the parent brand. Two shops in the same metro competing for the same searches need to be distinguishable to a search engine, and a single schema block at the domain level does not do that.

What it demonstrates

Multi-location work in the trades is mostly an information architecture problem. Getting the data model right first is what makes the third location cheap.