How to Build an Ecommerce Website With SEO Built In From the Start
Building it in is a sequencing decision rather than an extra service. The research that decides the category structure has to happen before anybody opens a design tool. Doing it the other way round means paying for the same work twice.
What Building It In Actually Means
The structure of the shop is derived from what people search for, which means the research has to come before the design. That is the whole of it. Everything else described as building search in is something applied to a structure already decided.
What the phrase usually means when an agency says it. Page titles written properly. Descriptions filled in. Image descriptions completed. A sitemap generated. All useful, all necessary, every one applied to a shop whose structure was settled weeks earlier by somebody who was not thinking about search at all.
That is not building it in. It is finishing it off, underneath a ceiling that was fixed before it started.
What it means here. The category tree is an output of demand research rather than an inheritance from the old site, the supplier's catalogue or the way the business is internally organised. The addresses follow a pattern chosen deliberately. The page types exist because somebody established they were needed.
None of that is an additional service with a price attached. It is the same project in a different order. The rest of this guide sets out what that order is, who has to be present for it and what it costs to discover it afterwards instead.
The Decisions That Have To Be Made First
Five things have to be settled before anything is designed. What they share is that changing any of them afterwards costs considerably more than deciding it correctly at the outset.
Category structure. How the catalogue divides and how deep it goes. Changing it later means a new address for every category that moves, a redirect from every old one, internal links reworked throughout and a period during which visibility is unsettled.
Category naming. The words are not labels. They are the terms the page will be found for. On most platforms they also form part of the address, so renaming a category is an address change wearing a different hat.
The address pattern. Whether a product sits directly beneath the domain or inside its category path. Once a shop is live and other sites have linked to it, every change needs a redirect, redirects accumulate and some external links are never updated at all.
Filter handling. Which filtered views are intended to exist as pages and which are not. Retrofitting this means removing pages that have already been found and indexed, which is slower and messier than never creating them.
Which page types exist at all. Adding a guide later is easy. Discovering that your whole catalogue needed a page type nobody built is not, because the template work and the structure work reopen together.
Research Feeding The Structure
Demand research is not a list of terms to insert into pages. It is the thing the category tree is built out of, which is a different use of the same work.
What it establishes. The words customers actually use, which are rarely your product names. Which groupings have real demand behind them and which exist only in your head. Where demand exists for a grouping you have never created. And how all of that moves across a year, since most catalogues have seasons whether or not the business thinks of itself as seasonal.
Why a structure inherited from a product feed rarely fits. This is the failure we see most. It is not carelessness. A supplier's feed is organised around how that supplier manufactures, warehouses and distributes. It divides by range, by production line, by brand hierarchy or by whatever the supplier's own systems needed.
Customers do not think in any of those terms. They think about a problem, a room, an occasion, a compatibility or a job to be done. A catalogue structured from the feed therefore produces categories organised around somebody else's operations, with names nobody searches for. It feels tidy from the inside while receiving almost nothing from outside.
The corrective is unglamorous. Put the demand list and the catalogue side by side and look for the three kinds of gap: demand matching products you have never grouped, groups you maintain that nobody searches for, plus demand for things you do not stock.
Who Needs To Be In The Room
Four parties, at the point structure is decided rather than afterwards. The order matters less than the fact that all four are present at the same time.
Whoever is responsible for search. They bring the demand work from block three. They are there to make the structure argument while it can still be acted on rather than to inherit the result.
The designer. They need to know which page types must exist and what has to fit on each, because a template designed before that conversation will not have room for it.
The developer. They establish what the chosen platform will actually do with the proposed structure, which occasionally reshapes it and always prevents a plan that cannot be built.
The client. The most easily forgotten and frequently the most useful. They know which products sell together, what customers ask before buying and which categories the business has argued about for years.
How we run it. One working session, with the demand and catalogue mapping already done and circulated beforehand. The output is a written structure document covering the category tree, the naming, the address pattern, the filter decisions and the page types. It is agreed before any design work begins. It is what the design is then drawn against.
What goes wrong without it is not dramatic. The structure simply gets decided by whoever was available at the moment somebody needed to start building.
What Happens When It Is Added Afterwards
A shop launches. Some months later somebody is engaged to improve its visibility, looks at the structure and finds it does not match how anybody searches. This is the common case rather than the unlucky one. Here is what follows.
The structure work happens anyway. Everything in block three gets done, just later and with a live shop constraining it.
Every affected category gets a new address. Which means a redirect from each old one, tested rather than assumed.
Internal links are reworked throughout. Menus, breadcrumbs, related products and any content pointing at the old arrangement.
Visibility becomes unsettled for a period. Addresses have changed, redirects have to be followed and processed, so positions move about before they settle. Weeks rather than days, on a shop that is trading throughout.
Content written for the old structure frequently does not fit the new one. Category copy written about a grouping that no longer exists in that form has to be rewritten rather than moved.
Which is the point worth taking from this block. The later version is not the earlier version arriving late. It is the earlier version plus a migration. Migrations are their own discipline with their own risks, covered in our site migrations guides.
The Cost Difference
We will not quote a multiplier for this, because any figure would be somebody else's project presented as arithmetic. What can be done is listing what each route contains, which is more useful anyway.
Doing it in sequence. The demand and catalogue mapping. The structure session. The structure document. Design drawn against it. Content written once, for the arrangement it will live in. Build, test, launch.
Doing it afterwards. Everything in that list, because none of it becomes unnecessary. Then, in addition: redirects from every changed address. Reworked internal linking. Rewritten content where the old copy no longer fits. Design adjustments where the new structure does not sit comfortably in templates drawn for the old one. A settling period on a trading shop. And the management time of running all of that while the business is operating.
Set out that way the comparison answers itself without a number. The second route contains the whole of the first route and then a migration on top.
There is one further cost that never appears on any invoice. During the months between launching on the wrong structure and correcting it, the shop was operating below what it could have reached. Nobody bills for that and nobody measures it, which is precisely why it is the easiest cost in the project to accept without noticing.
What We Do
Described plainly so it can be held against a design only quote, which is the comparison most buyers are actually making.
Before design. Demand research, a catalogue audit and the two mapped against each other. A structure session with everybody from block four. A written structure document covering the category tree, naming, address pattern, filter handling and page types.
During design. Each page type drawn around the job it has to do, with room for the content that has to exist on it rather than content trimmed to fit a layout already approved.
During build. Addresses, filters and pagination implemented as specified rather than left at platform defaults. Content scheduled inside the project with named owners and dates.
At launch. Redirects where a site is being replaced, tracking confirmed working, sitemaps submitted and the construction block removed, which is the most commonly forgotten step in this industry.
What this is not. It is not ongoing search work. Understanding how demand shifts, improving category content, earning references and responding to competitors is continuous, it belongs in our ecommerce SEO guides and it is bought separately.
The distinction that matters commercially: this is one piece of work rather than a design quote with a search quote attached. Why those two cannot sensibly be separated is the argument in how web design affects ecommerce SEO.
What To Ask Any Builder
Six questions, written to be used on any agency including this one. A page that only worked as an argument for hiring us would not be worth publishing.
At what point in the project do you decide the category structure? The answer you want is before design. The answer you will often get is during build.
What informs it? Listen for demand research and a catalogue audit. Listen out for the existing site, the supplier feed or the internal organisation, which are the three inheritances from block three.
When do you settle the address pattern and filter handling? Both should be decided in writing before anything is built. Somebody who has thought about it will say so without prompting.
Who is in the room when structure is decided? If nobody responsible for search is present, search is being applied afterwards whatever the proposal says.
What happens if we need to change the structure after launch? A supplier who describes redirects, reworked linking and a settling period is being accurate. One who calls it simple has not done it.
Is search structure in scope or excluded? Get the answer in the proposal rather than in a meeting.
If the answers are consistently that these things are looked at later, you are buying a design and you will pay for the structure twice. Further questions worth putting to any supplier are in how to choose an ecommerce web design agency.
Structure first.
Then design.
Demand and catalogue mapped before anything is drawn, a written structure document agreed before design begins, plus addresses, filters and pagination settled on paper rather than left at platform defaults. The same work, in the order that makes it count.
What a build covers:
Ongoing management afterwards sits inside our fixed monthly fee. Build work is quoted per project.
Twenty guides.
One subject.
This page covers the order of work. The rest of the series covers what a build costs, how long it takes, which platform suits which business and what each page type has to do.
