Home/Case studies/Warehouse Services UK

Case study · Logistics

A 5,240-page logistics platform, built to be found.

Warehouse Services UK needed to be the answer when a business searches for pallet storage, fulfilment or freight in a specific Midlands town. We built the platform that makes that true — service by service, town by town.

What did GTX Digital build for Warehouse Services UK?

GTX Digital built the entire public platform for Warehouse Services UK: a service architecture covering more than twenty-five logistics services, a service-by-location content cluster that now runs to 5,240 URLs, a technical insights library, a recruitment section with its own location hubs, and the structured enquiry flow that feeds the sales team. It is a custom build rather than a CMS theme.

  • Every service crossed with every town in the operating radius.
  • Around 3,400 words of genuinely local content on a location page.
  • Structured data generated from the same data the page renders.

The brief

Logistics is bought locally and searched specifically.

A business looking for pallet storage does not search for “logistics solutions”. It searches for pallet storage in the town it needs it, and it compares three suppliers on facts: location, rate, access and how fast they can go live.

WSUK had the operation and the Golden Triangle position to win that comparison. What it did not have was a site that said so, in the terms buyers actually search, for each service and each town it covers.

The brief was to build that at the scale the opportunity deserved — without producing the thin, templated location pages that make a cluster this size a liability rather than an asset.

  1. Scale 5,240 URLs Services crossed with every town in the operating radius, plus hubs, insights and recruitment.
  2. Depth ~3,400 words On a location page: what is included, rates, local detail, process, FAQs and an enquiry form.
  3. Markup Three schema types BreadcrumbList, Service and FAQPage on every location page, generated from the page’s own data.

What we built

Six things, one platform.

Each one went live and started working before the next began. At this scale, a single big launch is how you discover a structural mistake 5,000 pages too late.

  1. A service architecture, not a page list

    Twenty-five-plus services each given their own page — pallet storage, fulfilment by channel, freight by mode, cross-docking, kitting, returns — with a hub that lets a buyer find theirs in one step rather than reading a brochure.

  2. A service × location cluster at scale

    Every service crossed with every town in the operating radius, each page written around that place’s actual road links, postcode districts and sector mix. The live sitemap carries 5,240 URLs.

  3. Location pages built to convert, not just to rank

    Each one carries what is included, a transparent rate position, a comparison table, local road and hub detail, a four-step process, FAQs, testimonials and an enquiry form — around 3,400 words of genuinely local content.

  4. A technical insights library

    Articles on DIRFT, the M69 and M42 corridor, bonded warehousing, block stacking versus racking and domestic transit times. Written to answer the questions logistics buyers actually search, and to support the money pages rather than sit beside them.

  5. A recruitment side to the site

    Driving, warehouse and FLT roles with their own by-location hubs, so the staffing arm of the business has the same reach as the logistics arm without diluting it.

  6. An enquiry and quoting flow

    Structured requirement capture on the page rather than a bare contact form, so an enquiry arrives with pallet counts, dwell time and location already attached and can be quoted the same day.

How it was built

What makes a cluster this size work.

Most location clusters fail for the same reason: the same paragraph with the place name swapped. Everything below exists to avoid that.

  1. Entity first, pages second

    One canonical statement of what the business is, who it serves and where, implemented consistently in the content and in Organisation markup. Search engines and assistants both reward a business that describes itself the same way everywhere.

  2. Answer-first writing

    Every page answers its defining question in the first forty to eighty words, under a heading phrased the way buyers ask it. That is what makes a passage liftable into an AI Overview or an assistant answer instead of a competitor’s.

  3. Structured data that matches the page

    BreadcrumbList, Service and FAQPage markup on every location page, generated from the same data the page renders, so it can never drift away from the visible content.

  4. Specifics over adjectives

    Postcode districts, motorway junctions, drive times and rate positions stated plainly. In logistics the buyer is comparing three suppliers on facts, and the one that will not commit to facts loses.

  5. An internal linking spine

    Service hub to service, service to its locations, location to its sibling towns and back to the service. Nothing in the cluster is more than two clicks from a hub, and nothing is an orphan.

  6. Built static, served fast

    A custom build rather than a CMS theme, so page weight stays low and Core Web Vitals are a design constraint rather than a remediation project.

Results

What we will and will not claim.

The client reports strong organic and AI search performance. We have not independently measured it, so it is not published here as a number.

What is verifiable from the live site is the build itself: 5,240 URLs indexed in the sitemap, structured data on every location page, and a content depth per page that very few competitors in the sector match.

What we would need before publishing a performance figure is the Search Console export and the AI visibility reports behind it. When a supplier shows you a ranking claim with no source, assume it is the best month they ever had.

For the client to supply

Figures we would publish

  • Organic impressions and clicks, before and after, from Search Console.
  • Indexed page count against published page count.
  • Share of answer across the assistant prompt set.
  • Enquiry volume and quality attributed to organic.

Beyond the website

The enquiry flow is the product.

A logistics enquiry that arrives as “please call me” costs a sales conversation before anyone knows whether it is worth having. One that arrives with pallet counts, dwell time, location and timescale attached can be quoted the same day.

So the enquiry capture is structured rather than a bare contact form, and it is on the page the buyer is already reading rather than two clicks away. The requirement is captured in the buyer’s own terms and lands in a form the operation can price against.

That is the difference between a website that generates enquiries and one that generates quotable ones — and it is usually worth more than another thousand visitors.

Why it matters

Enquiry quality over volume

  • Requirement captured at the point of interest, not after a call.
  • Location and service already attached, so routing is automatic.
  • Quotable the same day rather than after a qualifying conversation.
  • The same structure across 5,240 entry points.

Questions

The Warehouse Services UK build, answered.

What people ask when they see a site this size.

What did GTX Digital build for Warehouse Services UK?

The whole public platform: a service architecture covering more than twenty-five logistics services, a service-by-location content cluster that now runs to 5,240 URLs, a technical insights library, a recruitment section with its own location hubs, and the structured enquiry flow that feeds the sales team. It is a custom build rather than a CMS theme.

How big is the site?

The live sitemap lists 5,240 URLs. That is the product of crossing every service with every town in the operating radius, plus the service hubs, the insights articles and the recruitment pages. Each location page runs to roughly 3,400 words of content written for that place rather than templated across it.

How do you build a cluster that size without it being thin?

By carrying real local data and measuring the result. Each town has its own road links, postcode districts and sector mix, and each service frames that material differently, so two pages about the same town or the same service do not converge. We measure near-duplication on the written sections specifically, because a whole-page measure is flattered by shared headers and footers and hides the problem.

Does a page like that work for AI search as well as Google?

They reward overlapping things, which is why the same build serves both. Answer engines lift a self-contained passage that answers the question directly; generative assistants draw on a business that describes itself consistently everywhere and is corroborated by third-party sources. Answer-first structure, honest specifics and clean entity data serve all of it.

Can you do the same for our business?

If the shape fits: a real service range, a defined operating area and buyers who search by capability and location. It is not a fit for every business, and a cluster built where that demand does not exist is a liability rather than an asset. The first conversation is about whether the shape is there.

How long did it take?

It was built in phases rather than as one launch — the core service architecture first, then the location cluster, then the insights library and the recruitment side. Each phase went live and started working before the next began, which is how we prefer to build anything at this scale.

Next step

Does your business have the same shape?

A real service range, a defined operating area and buyers who search by capability and location. If that is you, this approach works. If it is not, we will tell you rather than sell you 5,000 pages nobody needs.