What 630 Products Teaches You That 30 Doesn’t
Almost every small online store inherits the same information architecture, and almost nobody chooses it on purpose. You install the platform, it gives you Categories, and you start filling them in. Mugs. Shirts. Stickers. Accessories.
That structure is a warehouse diagram. It describes where things are kept. It is genuinely useful to the person picking and packing, and it is close to useless for the person trying to buy a present for their father-in-law.
You can get away with that at thirty products, because thirty products fit on one page and the customer can just look at all of them. At six hundred and thirty you cannot. Here is what actually changes.
1. The category tree stops being navigation and becomes a filing cabinet
At small scale, categories are how people browse. At large scale, nobody browses. They arrive from a search, land on one product, and either convert or leave. Your carefully nested category tree is now mostly a thing crawlers walk and customers ignore.
The fix is to stop organising by what the product is and start organising by who it is for. On the store we run, the top level is five audiences rather than five product types. A mug and a sticker and a t-shirt can sit in the same collection because they are for the same person. That is what the visitor came in with.
2. Overlap is a feature, and it will make duplicate content if you let it
Once collections are audiences, products belong to several at once. A dog mug is in Pet Collection and also in the gift guide for the person who has everything. That is correct merchandising and a genuine SEO hazard, because you have just created several routes to the same product and potentially several thin pages describing it.
What we do about it: one canonical home per product, collections that link to it rather than reproduce it, and collection pages that carry their own real copy so they are not just filtered lists with a heading. If a collection page cannot justify its own paragraph of writing, it should not be a page.
3. Your sitemap becomes an operational system
At thirty products you never look at the sitemap. At six hundred and thirty it is the only way you know the catalogue is still intact. Ours runs to roughly 664 URLs across products, collections, editorial and pages, and it gets checked, because a silent failure there means whole sections of the store quietly stop being indexed and nothing on the front end looks any different.
The useful habit is counting. Know the number of product URLs you expect. When it changes and you did not change anything, something broke.
4. One image rule, applied 630 times
Consistency at scale is not a design problem, it is a rules problem. Thirty products can each get a considered photograph. Six hundred and thirty cannot, and the moment you start making individual decisions you get a grid that looks like four different shops.
So you write the rule down instead: the crop, the background, the margin, where the product sits in frame, what the first image always shows. Then it is applied mechanically. The interesting part is that the rule is worth more than any individual image, because the rule is what makes the grid look deliberate.
5. Editorial is not a blog
A blog is what a store adds because someone said it should have one. Editorial is different: it exists to catch the searches that happen before the buyer knows what they want.
Product pages answer “where do I buy this exact thing”. That is a small number of searches with high intent. Editorial answers “what do I get for a dad who says he wants nothing”, which is a very large number of searches with no intent at all yet, and which no product page can ever rank for.
If you are competing with marketplaces on product terms alone, you lose. The editorial layer is where a small store is actually allowed to win.
6. What we would do differently
Three things, honestly.
Write the image rule before the first product, not the hundredth. We wrote ours partway through and then had to go back. Retrofitting consistency across a live catalogue is significantly more work than starting with it.
Decide the collection structure before uploading anything. Products are easy to add and structural decisions are expensive to reverse once six hundred things depend on them.
Set up the measurement first. It is very easy to build a large store and only discover months later that you cannot tell which collection actually sells, because nothing was instrumented at the start. Analytics is not a launch task, it is a foundation task.
The short version
Small catalogues forgive bad structure because customers can see everything. Large catalogues do not forgive anything. Every weak decision gets multiplied by the number of products, and the only defence is deciding the rules before the volume arrives.
If you want to see what this looks like in practice, the whole thing is written up in our 630-product WooCommerce case study, with the structure, the collections and the editorial hub laid out.