Depot Pages: How a Multi-Location Fleet Website Should Be Structured

A fleet or commercial hire business with more than one depot needs one indexable page per depot, because a depot is the unit a buyer actually searches for and the unit your operation actually differs by. A single contact page listing six addresses answers none of the six searches that could have found you, and it gives a search engine nothing specific to classify. This article sets out what belongs on a depot page, how depot pages should connect to vehicle class pages, how to keep a growing set of them from collapsing into near-duplicates, and what to do when a depot opens, moves or closes.

Why a depot is a page and not a row

The first sentence answers it: a depot is a page because a buyer searching for commercial vehicle hire is almost always searching within a place, and a search engine can only match that search to a page that is about that place. A contact page that lists six addresses in a table is about six places at once, which means it is precisely about none of them. Google’s own SEO Starter Guide describes organizing a site so that content sits in clear, well-labelled sections and pages that both people and search engines can navigate. A multi-depot operator following that guidance arrives at one page per depot almost automatically, because each depot is a distinct thing a person will look for by name.

There is a second reason that has nothing to do with search. A procurement buyer evaluating a shortlist has to establish whether you can actually serve the sites they operate from. On a table of addresses, that is a research task: read the row, guess the coverage, call to confirm. On a depot page, it is a reading task: the page says what area the site covers, what it keeps, and when it is open. Moving that work from the buyer to the page is the entire argument for the structure.

The unit test for a depot page

Ask whether a customer can arrive at the location, collect a vehicle, or return one. If yes, it is a depot page. A yard used only for overnight parking with no customer access is not a depot page, it is an operational detail that belongs nowhere on the public site. Being strict about this keeps the set honest. Publishing a page for a location nobody can visit produces a page with nothing true to say, and pages with nothing true to say are the ones that read as filler.

What a depot page is not

A depot page is not a duplicate of the home page with a place name inserted. That pattern is well known and it is the reason many multi-location sites end up with a set of pages that a search engine treats as substantially the same. Google documents how duplicate and near-duplicate URLs are consolidated, which in practice means the effort spent producing eleven variations can end up represented by one. The way out is not clever rewording. It is publishing pages that differ because the underlying depots differ.

What belongs on a depot page

A depot page answers a specific sequence of questions, and answering them in that order is most of the design work.

Name. Use the name the depot is actually known by, including the informal one if that is what customers say. If the site is universally called the north yard, the page should not be titled by a street address nobody uses.

Address and access. The full postal address, plus the access detail that a driver arriving in a commercial vehicle actually needs: which entrance, height restrictions on the approach, where to park a car if they are swapping into a hired vehicle. This is the single most useful paragraph on most depot pages and the one most often missing.

Hours. Collection and return hours, which are frequently not the same, plus whatever the out-of-hours arrangement is. If there is no out-of-hours return, say so plainly. An unanswered question becomes a phone call, and a phone call at the comparison stage is a cost to both sides.

Vehicle classes kept here. Not the full fleet, the classes this site actually keeps. A buyer who drives to a depot for a refrigerated van that is only ever kept at a different site will not make that mistake twice, and they will not make it with you again either.

Coverage. The area this depot serves for delivery and collection, described in the terms the region is actually known by rather than as a radius in miles. Buyers think in places, not circles.

A direct enquiry route. A form or a number that reaches the desk responsible for this site, pre-tagged with the depot so nobody has to ask which location the enquiry is about. This is the difference between a depot page and a depot description.

The order matters more than the content

Every item above appears on most depot pages somewhere. What separates a page that converts from a page that exists is the order. Identify, locate, confirm availability, act. A page that opens with three paragraphs about company heritage and reaches the address at the bottom has inverted the reader’s priorities, and the reader responds by leaving. Answer-first ordering is not a stylistic preference on a depot page, it is the structure of the question being asked.

Cross-linking depots and vehicle classes

The most valuable structural decision on a multi-depot site is also the cheapest: link every depot to the classes it stocks, and every class to the depots that stock it.

This matters because the highest-intent searches in this category are compound. A buyer rarely searches for a vehicle class in the abstract or a depot in the abstract. They search for a class in a place. If your site has a page for the class and a page for the place, and the two link to each other with descriptive link text, then both pages carry a clear signal about the combination, and a reader who lands on either one is a single click from the other.

How the links should read

Link text should name the thing being linked to. A link that says see our vehicles tells a reader and a search engine nothing. A link that says refrigerated vans kept at this depot tells both exactly what is on the other end. The same applies in reverse: on a vehicle class page, list the depots that stock the class by name rather than linking to a generic locations page.

Keeping the cross-links true

The risk with cross-linking is drift. A class moves between sites and the links quietly become wrong, which is worse than not having them. The practical fix is to treat the class-to-depot mapping as a single source of truth that both page types read from, so the fleet mix is recorded once and both directions of linking are generated from it. On a managed site this is exactly the kind of change that belongs in a routine weekly update rather than in a development cycle, and it is one of the reasons the features of a managed build matter more than the initial design.

Avoiding the near-duplicate trap

A set of twelve depot pages assembled by find-and-replace is the most common failure in this category, and it fails in a way that is invisible until it matters.

Lead with what differs

Write the first two paragraphs of each depot page from the facts that are unique to that site. One depot has restricted overnight access. Another sits inside a distribution park with its own security procedure. A third is the only one with a tail-lift-equipped class kept on site. Those facts are genuinely different, genuinely useful, and impossible to produce by rewording. Once the specific material is on the page, the shared material can follow without doing any harm, because the page has already established what it is about.

Let the fleet mix carry the difference

The vehicle mix at each site is usually the largest true difference between depots, and it is already recorded somewhere in your operation. Surfacing it fully on each depot page does double duty: it differentiates the page and it answers the question a buyer actually has. A depot page that lists nine classes with the ones kept on site marked is more useful, and more different from its siblings, than a page of prose about the region.

Resist the temptation to pad

If a depot genuinely has little to distinguish it, a short honest page is better than a long padded one. Google’s guidance on creating helpful, people-first content is explicit that content should be written for people rather than to occupy space, and a short page that answers the six questions above completely is a helpful page. A long page that answers them among filler is not.

Structured data and the local signal

Depot pages are one of the few page types on a marketing site where structured data maps cleanly onto reality. Google Search Central documents local business structured data for pages representing a physical location, including the properties for address, opening hours and geographic detail. A depot page describes exactly that, so marking it up is a case of describing what is already visible rather than inventing a claim.

Two rules keep this safe. First, the structured data must match the visible page. Marking up opening hours that do not appear on the page is outside Google’s structured data guidelines and creates a maintenance liability besides. Second, mark up the depot, not the company, on the depot page. The organization as a whole is described once, on the home page. Repeating it on every depot page tells a search engine less, not more.

What structured data does not do

It is worth being plain about the limit. Structured data helps a search engine understand what a page is about. It does not make an unhelpful page rank, and it is not a substitute for the address actually being on the page in readable text. Treat it as the machine-readable copy of a page that is already correct for people.

Accessibility on a page people read in a vehicle

Depot pages get read in bad conditions: in a yard, on a phone, in daylight, often by someone already running late. That makes the accessibility basics unusually load-bearing here.

Addresses and phone numbers should be real text rather than images, so they can be selected, copied and read aloud. Phone numbers should be links that dial. Contrast should clear the WCAG 2.2 minimums, which matter more on a screen held at arm’s length in sunlight than they do in an office. Tap targets for the enquiry button and the phone link need to be large enough to hit without precision. Hours should be a list, not a paragraph, because a list can be scanned and a paragraph has to be read.

None of this is specific to fleet websites, but the usage conditions make the consequences of getting it wrong more immediate. A buyer in an office will squint at low-contrast text. A driver in a yard will give up.

Opening, moving and closing a depot

A depot set is not static, and the way the site handles change is part of the structure.

Opening

A new depot page should exist before the depot opens, with a clear statement of the opening date and a working enquiry route. That page will not rank on day one, and it does not need to. It needs to exist, be linked from the depot index and the relevant vehicle class pages, and appear in the sitemap so it can be discovered. Google documents sitemaps as a way to tell search engines about pages on your site, and a new page with few internal links is exactly the case where that helps most.

Moving

A depot that moves keeps its page if it keeps its identity, and the page records the move with the new address and the date it took effect. If the move is significant enough that the location is genuinely a different one to customers, treat it as a closure and an opening, and redirect accordingly.

Closing

Redirect the closed depot page to the nearest depot that now serves those customers. Google Search Central documents permanent redirects as the mechanism for telling search engines a URL has moved for good. Deleting the page and letting the URL return a not-found response discards whatever visibility it had, and it strands any external link pointing at it. The redirect target should be a page that actually helps the person who followed the old link, which is almost always the nearest operating depot rather than the home page.

The depot index, and why it is a real page

A site with depot pages also needs a page that lists them, and that index page does more work than it is usually given credit for.

It is the page a buyer reaches when they know they want you but do not yet know which of your sites is relevant. It is the page that gives every depot page an internal link from somewhere sensible, which matters for discovery on a site where new depots appear. And it is the page that answers the question a shortlist reviewer asks first, which is simply how many locations do you run and where.

Make the index scannable, not decorative

A depot index works best as a ruled list or table rather than a grid of identical cards. A buyer scanning for a region wants to run their eye down a column of place names, not read twelve boxes. Give each row the depot name, the area it serves, the classes kept there in short form, and a link. That is four columns of genuinely different data, which is exactly the kind of content a table is for.

Sorting matters more than it sounds. Alphabetical is predictable and therefore fast to scan. Sorting by size or by internal importance is invisible to the reader and makes the list feel arbitrary. If the set is large enough that scanning becomes work, group by region with a heading per group rather than adding a filter that has to be operated before anything is visible.

Keep the index and the pages in step

The index is generated from the same depot record the pages are built from, so a new depot appears in both places or in neither. An index that lists a depot with no page, or a page with no listing, is the specific failure that makes a site feel unmaintained, and it is entirely avoidable by treating the depot list as data rather than as markup typed twice.

One index, not several

Resist splitting the index into separate pages per region unless the set is genuinely large. Three regional index pages with four depots each is worse than one page with twelve rows: it adds a navigation step, spreads the internal linking thinner, and gives a reader three places to look instead of one. Split only when a single page stops being scannable, which in practice is well past the point most operators assume.

A maintainable set, not a one-time build

The reason most multi-location fleet sites end up with stale depot pages is not that nobody cares. It is that updating them costs a development request, and a development request for a change of opening hours never makes it to the top of the list. The structure above only works if changing it is routine.

That is the practical argument for a managed build over a one-time project: a depot that changes its hours, adds a class or moves its entrance produces a change to the site that week rather than at the next redesign. If you are weighing that up, the pricing page sets out exactly what a monthly plan covers and the fleet types pages describe how the structure differs for the kind of operation you run.

Start with the depots a customer can actually visit, give each one a page that answers the six questions in order, link them to the classes they keep, and keep the set current. That is the whole structure, and it is enough.