Not one page at a time. Above a few thousand products the work changes from editing pages to building rules, templates and data quality that improve thousands of pages at once.
The methods that work on a five hundred product store do not scale. You cannot write fifty thousand descriptions, and you cannot check fifty thousand pages by hand.
What you can do is find the patterns. Most problems on a large catalogue affect a category of pages rather than individual ones, which means one correct fix can move an enormous amount of the site at once.
What Breaks First on a Large Catalogue?
Index coverage, duplicate pages and crawl waste. On a large store these are not tidy up tasks, they are the main event, because the volume makes small percentages expensive.
Each of these is measured as a percentage of the catalogue rather than as a list of pages, because a list of ten thousand pages is not something anyone can act on.
How Do Templates Replace Writing Every Page?
A good template builds a genuinely different page for each product from that product’s own attributes, so the page reads specifically about that item rather than filling blanks in a shared sentence.
The difference between a useful template and a bad one is where the content comes from. A bad template inserts the product name into a fixed sentence, producing fifty thousand nearly identical pages, which is worse than no description at all.
A good template assembles a description from the attributes that actually vary. Materials, dimensions, compatibility, use cases, what it is usually bought with, what it should not be used for. Products with rich data produce rich pages. Products with thin data produce thin pages, which is why data work comes first.
The top few hundred products still get written by hand, because they carry a disproportionate share of the revenue and deserve it. The template handles the long tail, which is most of the catalogue and most of the missed opportunity.
How Do You Report on Something Too Big to Look At?
By segment. We split the catalogue into groups that make commercial sense and report each one separately, because a single site wide number hides everything useful.
A large store reporting one traffic figure learns nothing. Half the catalogue can be growing while the other half collapses and the total looks flat.
So we agree segments at the start, usually by product category, sometimes by brand, margin or supplier. Every report then shows index coverage, traffic, rankings and revenue for each segment against the baseline.
This also changes what gets worked on. When you can see that one category has thirty per cent of its products unindexed while another has two per cent, the priority decides itself.
How Do You Decide What to Fix First Across Fifty Thousand Pages?
By finding the pattern behind each problem and sizing it as a share of the catalogue. One rule that affects twelve thousand pages is worth more attention than a hundred individually broken ones.
On a large store the useful question is never which page is broken. It is what kind of page is broken, and how many of that kind exist. A problem that appears on three products is noise. The same problem on a third of the catalogue is the quarter’s main project.
So the first pass groups every finding by cause rather than by page. Missing a field on all products from one supplier. Slow loading on every page built from one template. Thin content on every collection created automatically. Each of those has a single fix that resolves thousands of pages at once.
The second pass sizes each group by the revenue involved, using the categories the business already thinks in. That produces a list a commercial team can make decisions from, rather than a technical list they have to take on trust.
The result is usually a surprisingly short plan. Five or six rules, each affecting a large share of the catalogue, will normally account for most of the available gain in the first year.
Who Does the Work When Changes Need a Developer?
Usually your development team or platform partner, with us writing the specification, checking the result and taking responsibility for whether it worked.
At this scale most changes go through a release process. We are not going to be given direct access to a system running your business, and we would not expect to be.
So our job changes shape. We specify precisely what needs to change and why, in a form a developer can act on without interpreting marketing language. We test on staging before release. And we verify after release, because a change that ships incorrectly and is never checked is worse than one that never shipped.
This works well when there is one person on your side who can get things into a release cycle. Where that person does not exist, work stalls, and we will say so early rather than letting it drift for a quarter.