← Back to Marketing Analytics Consultants

Case study · Website performance and search visibility

A 300,000-item catalog, and the work of making it findable

A specialist e-commerce operation with a very large archive catalog, a serious Google footprint and a persistent question: is any of this working? This is the measurement program that answered it — what was instrumented, what the data showed, the projects that came out of it, and what happened when they shipped, including the part that went backward.

1. Start by measuring, not guessing

The owner’s theory was that the site was slow. That turned out to be true, and also not the whole answer. Before changing anything we pulled every source of evidence the site could produce, because a single tool only ever shows you a single face of the problem.

SourceWhat it answersWhat it showed here
PageSpeed Insights / LighthouseIs the page fast for a real person on a phone?Performance 58 of 100. One metric catastrophic.
Google Search Console — coverageDoes Google index the pages at all?66,800 indexed. 435,000 not.
Search Console — crawl statsWhere does Google spend its time here?Over a third of it wasted on a duplicate host.
Search Console — performanceWhat are people actually searching for?998 clicks in three months, average position 8.8.
Google Analytics 4Who arrives, and from where?About 71,000 users a month.
Platform analyticsSame question, different counter181,073 “visits” — because it counts crawlers.
Order and profit recordsWhich items actually sell, and at what margin?Demand is real but thin, and spread across thousands of distinct items.
The first useful finding was a contradiction

The platform reported 181,073 visits. Analytics reported around 71,000 users. The gap was not an error — the platform counts robots and the analytics tool filters them out. An owner reading only the platform dashboard had been looking at a number roughly two and a half times larger than the human audience, for years.

A note on what we did not use as the measure

This is a deliberately niche catalog — archival and historical material with a small, specialist buying audience. Raw sales volume is a poor instrument in a category like that, because it moves with demand for the subject matter rather than with the quality of the site. So the program was built to measure the things the operator can actually control: whether pages load, whether Google can reach them, whether the listings describe what is on them, and whether the people arriving are the people the pages were written for.

299,922products in the catalog
66.8Kindexed by Google
502KURLs Google had discovered
7measurement sources cross-checked

2. The speed problem, and how narrow it was

The homepage took 67 seconds to paint its main content on a mid-range phone. Google’s threshold for “good” is 2.5 seconds. That is not a slow page; that is a page most people will never see.

Where the page weight actually satImagesthe problemTheme CSS and JSminorThird-party scriptsminorFontsnegligibleEverything elsenegligibleOne cause, not a general slowness. That is what made it fixable.
Most speed problems are diffuse. This one was almost entirely images.

But the diagnosis mattered more than the number. The parts of the report that usually indicate a badly built site were all fine — blocking time was 30 milliseconds, layout shift was zero. The problem was one thing only.

Figure 1

Twenty megabytes of a twenty-one megabyte page were images

Image payload the audit said could be removed, in KiB 18 July 20,557 KiB 24 July 1,012 KiB Total page weight at the start was 21,768 KiB. Roughly 20 MB of a 21 MB page was images served near full resolution, in legacy formats, with no responsive sizing.

Source: PageSpeed Insights, Lighthouse 13.4.0, emulated mid-range Android on Slow 4G, homepage, 18 July and 24 July 2026. No field data was available - the site has too little real-user traffic for Google to report it, which is itself a finding.

Why this is worth saying out loud

A general recommendation to “improve site speed” would have sent money at JavaScript, hosting and theme rebuilds. None of those were the problem. The fix was a single, cheap, well-defined job: resize the images, serve modern formats, size them responsively.

3. The bigger problem was invisible in the browser

A site can be fast and still be unfindable. Search Console told a different story, and a worse one. Google knew about roughly 502,000 URLs on a site with 300,000 products, and had indexed 66,800 of them.

What a browser shows against what a crawler findsLooks fine in a browser— Pages load— Images appear— Navigation works— Nothing visibly brokenWhat the crawl found— Crawl budget spent on dead URLs— Index coverage far below page count— Metadata missing at scale— Feed and canonical conflictsNobody finds these by looking at the site. They are found by measuring it.
The visible problem was speed. The expensive problem was that most pages were never being indexed.

Figure 2

A quarter of a million pages found and never looked at

Google’s view of the site: 502,000 known URLs against a 300,000-product catalog Indexed 66,800 Discovered, never crawled 254,886 Crawled, not indexed 106,213 Blocked by robots.txt 69,016 A quarter of a million pages Google had found and never bothered to look at. After both crawl leaks were closed, the site was still only being crawled at about 1,300 to 1,400 product pages a day - roughly 214 days for one complete pass.

Source: Google Search Console index coverage report, July 2026.

Two specific leaks were found, and both were configuration rather than content.

Figure 3

Where the crawl budget was actually going

312,038 crawl requests over ninety days, by host bare domain 197,910 www copy 114,061 36% of the crawl budget went to fetching a duplicate host, to read a tag saying “ignore me”. Same ninety days, by file type HTML 56% JSON 39% The JSON was an internal option-data endpoint, fetched once per product page and never needed for indexing - about 122,000 requests in a quarter.

Source: Google Search Console crawl stats, ninety-day window, July 2026.

LeakCauseFix
Duplicate hostThe platform’s www redirect setting was left on “no preference”, so the entire catalog answered on two hostnamesSet to redirect www to the bare domain
Internal data endpointGoogle was crawling a JSON options endpoint once per product page. The site’s robots file blocked an obsolete path that no longer existedAdded the real path to robots.txt, verified live
The honest limit of the fix

Both leaks were closed and confirmed. Even so, the site is crawled at roughly 1,300 to 1,400 product pages a day — about 214 days for a single complete pass of the catalog. Closing the leaks bought real headroom. It did not make a 300,000-page catalog sustainable at this domain’s authority, and we said so rather than declaring victory.

4. What the pages actually said

A written specification for product titles already existed. It was clear and it was sensible: subject, then year or era, then image type; never catalog codes. We measured the live catalog against it.

Figure 4

The specification existed. Two percent of the catalog followed it

Share of 299,922 product titles meeting the specification that had been written for them Carries a year or decade 7.3% Uses the required separator 33.2% Meets both 2.1% What had shipped instead: eight generic suffixes rotating in near-equal proportions across 266,448 titles - 88.8% of the catalog, each suffix within half a percent of the others. That even a split is a round-robin loop, not editing. 23,914 titles were also cut off mid-word.

Source: analysis of a full 299,922-row catalog export, July 2026, tested against the written title specification.

What had shipped was the original archive record with a generic phrase bolted on the end. The give-away was the arithmetic: eight different suffixes appeared 26,200 to 27,200 times each. Real editorial choices do not distribute that evenly. That is a loop.

And the search data said something nobody expected

The top queries bringing people to the site were personal names, town histories and genealogical terms — not wall art, not decor, not any of the commercial language the listings had been optimized toward. The site had an audience. It was researchers, and the pages had been written for shoppers.

5. The program of work, over several years

None of this was a single engagement. It is a sequence of projects, each one aimed at a specific measured fault, run over a period of years as the evidence accumulated.

ProjectWhat it addressedScale
Master product databaseOne source of record feeding the website and every marketplace, instead of maintaining each platform by hand~300,000 items
Feed engineeringFlat files, variant templates and partial-update feeds across platforms with incompatible rulesMulti-channel
Archive record matchingJoining every product back to its source archive record to recover the date, place and subject that had been lost in the listing273,807 records matched at 96.9%
Customer-facing category buildReplacing internal archive collection names with categories a customer would actually search for286 categories
Metadata and description rewriteSystematic rewrite of product titles and descriptions across the catalogCatalog-wide
Title specification and auditA written standard for product titles, then a measurement of how much of the catalog met it299,922 titles tested
Crawl budget correctionDuplicate host and internal data endpoint, both leaking Google's crawl allowance~36% and ~39% of crawl
Image delivery rebuildResize, modern formats and responsive serving on the heaviest pages~20 MB removed per page
Listing repositioningMarketplace keywords and copy retargeted after the query data showed who was actually arrivingOngoing
The pattern worth noticing

Every one of those projects was defined by a measurement, not by a hunch. The category build came from a density comparison against a competitor. The title standard came from an audit that counted how many titles carried a date. The crawl work came from a report nobody had opened. That is the difference between a plan and a to-do list.

6. What shipped most recently, and what happened

Three workstreams, in priority order: the image payload, the two crawl leaks, and the title and category rebuild. The first two were done inside a week. The third is a larger job and is underway.

The image work was carried out by an outside developer for a fixed fee. It did exactly what it was asked to do.

Figure 5

The target metric improved by 78 percent

Largest Contentful Paint, seconds - mobile, Slow 4G, emulated handset 18 July 67.1s 24 July 14.7s Google’s “good” threshold: 2.5s A 78% improvement that still scores zero out of twenty-five on this metric.

Source: PageSpeed Insights, identical test conditions, 18 July and 24 July 2026. Lab results vary between runs; a figure like this should be re-tested three times and the median quoted before it is used anywhere it matters.

And then the overall score went down.

Figure 6

One change, three categories worse

Lighthouse category scores, out of 100 18 July 24 July Performance 58 49 Accessibility 89 85 Best Practices 96 96 SEO 92 85 Three of the four went down. Only one thing had been changed.

Source: PageSpeed Insights, identical test conditions, 18 July and 24 July 2026.

This is the part most reports leave out

Faster painting earned about nine points. A new layout-shift problem cost seventeen. Resizing the images had stripped the explicit width and height attributes, so nothing reserved space on the page any more and the content jumped as it loaded. The same pass also dropped image alt text, which is why the accessibility and SEO scores fell at the same moment.

None of that makes the image work wrong. It was the right job and the payload result proves it. It makes the job incomplete, and the only reason anyone knows that is that the same test was run under the same conditions before and after.

Measure18 July24 JulyRead
Removable image payload20,557 KiB1,012 KiBFixed
Largest Contentful Paint67.1s14.7sMuch better, still failing
First Contentful Paint5.1s3.1sBetter
Render-blocking requests2,950ms940msBetter
Cumulative Layout Shift00.352New problem introduced
Accessibility8985New problem introduced
Unused JavaScript / CSS117 / 37 KiB117 / 37 KiBUntouched

The next brief was seven items in priority order, starting with the width and height attributes because that single change is worth roughly seventeen points on its own. It also asked the developer two direct questions: what exactly shipped, and was the alt text removed or had it never been there. Both matter, and neither is answerable from the outside.

7. What this case is meant to show

Not that we made a site fast. We did not, yet.

What it shows is a way of working. Measure before touching anything. Use more than one source, because a single dashboard will lie to you by omission. Name the specific cause instead of the general category. Re-measure under identical conditions afterward, and report the regression as loudly as the improvement.

The usual approachWhat was done here
“Your site is slow, let’s rebuild it”Twenty of twenty-one megabytes are images. Fix the images.
Report the metric that improvedReport the one that improved and the two that broke
One tool, one numberSeven sources, cross-checked against each other
Traffic is the goalTraffic was never the gap. Who was arriving, and what the pages said to them, was
The finding the owner did not expect

The most valuable thing to come out of this was not the speed number. It was discovering that the people arriving from Google were researchers and genealogists looking up names and places, while every page had been written to sell decor. That is not a performance problem. It is a positioning problem, and it was only visible because someone read the query data.

Marketing Analytics Consultants

Would this kind of read help your site?

We look at what your site is doing, tell you what we find in plain language, and separate the things worth money from the things that are fine. We do not build websites, so we have no reason to tell you that you need one.

Prefer email? info@marketinganalyticsconsultants.com