Skip to content
Case study · E-commerce and retail

Specialty retailer with several stores: stabilizing a bot-crushed shop and moving it to a light headless site

A store with thousands of products kept going down under a swarm of bots crawling filters; KINTO stabilized it in days and migrated it to a headless shop whose listing weighs ≈1% of what it did.

By KINTO · Published

Figures, each with its source

  • over a thousand (from a public catalog of several thousand)

    products migrated from WooCommerce

    Measured

  • from several MB to ≈0.1 MB

    store listing weight

    Measured

  • from ≈3 s to ≈0.5 s

    response time on filter URLs

    Measured

  • a reproducible exclusion policy

    what appears in the channel

    Measured

Ranges or orders of magnitude where a figure could identify the client, each with its source.

How the transformation unfolded From the problem to what changed, in the five steps every KINTO case follows.

  1. Problem

    The WooCommerce store went down intermittently: a swarm of bots crawled the combinatorial explosion of filter URLs, bypassed the cache and saturated the database.

  2. Signals

    Four signals: market, business, user experience and support.

  3. How we understood it

    We ran a diagnosis of the server (access logs of tens of gigabytes, root cause proven), analyzed the source catalog and reconciled it against the client’s Excel inventory.

  4. What we built

    An immediate stabilization of the old site, a programmatic migration with brand and type enrichment, a headless store with mobile-first search and filters, and a reproducible exclusion policy driven by the client’s Excel.

  5. Transformation

    The store listing went from several MB to ≈0.1 MB, filter URLs from ≈3 s to ≈0.5 s before migrating, and what appears in the channel is governed by a reproducible exclusion policy.

Before and after, by dimension Editorial levels from 0 to 4 read from the text of this case, never a figure drawn to scale.

  • Store stability

    Before

    Down intermittently (level 1 of 4)

    After

    Stable (level 4 of 4)

  • Listing weight

    Before

    Several megabytes (level 1 of 4)

    After

    Very light (level 4 of 4)

  • Product data

    Before

    Poor, no brand or type (level 1 of 4)

    After

    Brand and type (level 4 of 4)

The four signals we read What the market, the business, the user experience and support were saying before KINTO built anything.

  • Market

    Market demand was not measured in this engagement: the problem was technical and about data quality.

  • Business

    A retailer with several physical stores and free in-store pickup.

  • User experience

    The store listing weighed several megabytes, and the filters were useless and hard to use on mobile.

  • Support

    WhatsApp support per store and a store locator map.

From proven cause to one exclusion source
  1. Server diagnosis Large logs, root cause proven
  2. Catalog vs. inventory Reconciled against the client’s Excel
  3. One exclusion source With tests and CI
  4. Headless store Mobile-first search and filters

Connections

  • Server diagnosis → Catalog vs. inventory
  • Catalog vs. inventory → One exclusion source
  • One exclusion source → Headless store

A store with thousands of products kept going down under a swarm of bots crawling filters; KINTO stabilized it in days and migrated it to a headless shop whose listing weighs ≈1% of what it did.

Problem

The WooCommerce store went down intermittently: a swarm of bots crawled the combinatorial explosion of filter URLs, bypassed the cache and saturated the database. On top of that: thousands of products with poor data and zero prices from a mapping error.

Signals

  • Market: Market demand was not measured in this engagement: the problem was technical and about data quality.
  • Business: A retailer with several physical stores and free in-store pickup.
  • User experience: The store listing weighed several megabytes, and the filters were useless and hard to use on mobile.
  • Support: WhatsApp support per store and a store locator map.

How we understood it

  • Server diagnosis: access logs of tens of gigabytes, root cause proven.
  • Source catalog analysis and reconciliation against the client’s Excel inventory: thousands of products matched, hundreds with no match.

What we built and why

  • Immediate stabilization of the old site: early response to filter URLs without touching the database, filtering of the bot traffic at the CDN, and disk cleanup.
  • Programmatic migration to the commerce platform, with image repair and brand and type enrichment on thousands of products (dry run by default).
  • Headless store with search, bottom-sheet filters for mobile, a stable category hierarchy, cart, WhatsApp per store, a map, llms.txt/ai.txt and segmented sitemaps.
  • Reproducible exclusion policy driven by the client’s Excel, with tests and continuous integration: an excluded product appears in no page, search, sitemap or AI file.

Why this way: The exclusion comes from one source so it applies everywhere (pages, search, sitemaps and AI files), with tests and continuous integration.

Transformation

  • Store listing from several MB to ≈0.1 MB (static pagination).

  • Filter URLs from ≈3 s to ≈0.5 s and bot traffic cut to a fraction, before the migration.

  • What appears in the channel is governed by one reproducible exclusion policy.

  • Thousands of products enriched with brand and type.

  • products migrated from WooCommerce: over a thousand (from a public catalog of several thousand) (measured)

  • store listing weight: from several MB to ≈0.1 MB (measured)

  • response time on filter URLs: from ≈3 s to ≈0.5 s (measured)

  • what appears in the channel: a reproducible exclusion policy (measured)

What we don’t know yet

  • Later sales and conversion: no evidence.
Case studies

Related case studies

Have a problem like this?

Tell KINTO what is going on. The first conversation is to understand it, not to sell.

Book a call Contact