A pump manufacturer with 42 pages and no way to find a pump

A buyer lands on your site.

They've got a fluid, a flow rate, and a problem.

They need to know which of your pumps handles it.

On Torqueflow-Sydex's old site, they had to open a dropdown longer than the screen, scroll past a hidden overflow menu, and guess.

That's not a design problem. That's a sales problem wearing a design costume.

Torqueflow-Sydex is the UK arm of Sydex, an Italian manufacturer of progressing cavity pumps. Southampton-based. Real engineering pedigree — they build pumps for the fluids nobody else wants to touch: abrasive sludge, biogas digestate, 80% solids, food-grade product that can't be sheared.

Their website was built in Wix Classic around 2019 — and added to ever since.

Seven years of new products, arriving one at a time, into a structure built for a smaller range.

A buyer researching a £50,000 pump specification arrives on the site and can't tell what makes Sydex the right choice, or how to ask. That's the core problem. Everything else is a symptom.

What we actually found

We audited all 42 pages before we touched a design tool — user experience, conversion, SEO, technical. We won't itemise someone else's site in public. But the shape of it will be familiar to anyone running a catalogue on a build that's aged.

The navigation had outgrown the buyer. Products had been added to a menu structure that was never designed to hold them. It worked when there were twelve. It didn't at forty.

The URLs had grown the same way. Pages duplicated rather than templated — which, in Wix Classic in 2019, was more or less how you added a product. The platform didn't offer much else. But seven years of it leaves a trail search engines can read, and buyers can see in the address bar.

Small things, compounding. A rendering bug above the fold. Copy that had drifted on the exact terminology a technical buyer judges you by. A mobile contact route that no longer landed where it said it would. Any one of them is a five-minute fix. Nobody had five minutes, for seven years.

The SEO settings were arguing with the business. Some of the technical configuration was actively telling search engines not to rank the pages we needed ranked.

And the contact form couldn't qualify anything. Name, email, and a message box. A buyer specifying a £50,000 pump was given the same form as someone asking for a brochure.

None of it is catastrophic on its own. That's the thing about sites like this — nothing's broken enough to force a decision. It just quietly costs you enquiries every week until someone counts.

And here's the part worth saying plainly, because case studies like this usually skip it: none of that is a criticism of whoever built the original. In 2019, on Classic, with a range a third of the size, that was a reasonable site. The tools were different. The catalogue was smaller. Somebody did the job in front of them, and it worked for years.

The 2019 build on the left, the 2026 rebuild on the right. Drag the handle.

No website breaks all at once. It gets added to, one product at a time, until the structure that used to fit doesn't. That's not neglect. That's a business outgrowing its container.

How we ran it

We don't do six-week discovery phases. We audit, we agree on the architecture, we design the templates, we build, we test, we hand over. In that order, and the order matters.

1. Audit first.

42 pages reviewed — UX, conversion, SEO, technical — before anything was scoped. That's what proved this was a data architecture job and not a redesign. Quote first and you quote for the wrong project.

2. Structure before design.

Sitemap, URL architecture and database schema agreed before anyone opened a design tool. Which fields does a product have? How does a product know which industries it serves? Get that wrong and you're rebuilding in month four.

3. Templates before pages.

We designed four templates — homepage, product, industry, contact — and got them signed off. That's the one review that really counts. Everything after it is execution.

Ten industry pages. One template. One CMS collection.

4. Build.

Wix Studio, on a proper design system: two brand colours, a defined type scale, one set of components. Two CMS collections, cross-referenced.

5. QA that's actually adversarial.

More on this below.

6. Handover.

Their team can add a product without ringing us. Your website shouldn't need a developer every time you want to publish — that's the whole point.

The most important meeting on any build is the one where you agree the database schema. It's also the one clients least expect to have.

Two databases instead of forty-two pages

Here's the shift that made the project work.

The old site had a page per pump, each one hand-built and slightly different from the last. We replaced that with two CMS collections — Products and Industries — and two templates that build every page from them.

One catalogue, two collections, 44 pages.

Products know which industries they serve. Industries know which pumps suit them. A buyer on the Biogas page sees the pumps proven in biogas. A buyer on the Syflex page sees which sectors run them. That cross-reference is live, not hand-maintained.

The cross-reference, rendered. The K Range knows which sectors it serves — because the database does.

Underneath it sits the detail:

10 product categories, a key advantages table of about 136 rows, and a performance spec table of about 102 rows. Every product page assembles itself from those.

Key advantages and performance specs — assembled from child tables, not typed out by hand.

Then this happened:

We quoted for 15 product pages and 9 industry pages. We delivered 34 and 10.

The range grew mid-project — the full Ampco hygienic and centrifugal lines came in, plus the brewery equipment. On the old site, that's 20 more pages to hand-build at £250 a page. On a template system, it's rows in a database.

The product range more than doubled mid-project. The page count didn't cost more. That's what you're actually buying when you buy a CMS.

The bit nobody talks about: getting the catalogue in

Here's the part that usually kills projects like this.

The content isn't the problem. The content exists — it's in PDFs, on old pages, in brochures, in the parent company's catalogue. The problem is that moving it into a structured database is brutal, boring, error-prone work. Hundreds of specs. Every viscosity range, every flow rate, every certification, every material option, each one needing to land in the right field on the right record.

Historically, that's months of copy-paste. It's why most manufacturers never do it, and why their product data stays stuck behind a "Downloads" link.

We used AI to do it in weeks.

Not to write the content — to restructure it. Scrape the existing pages and brochures, parse the specs into fields, map every product to its category and its industries, generate the slugs, draft 44 sets of SEO metadata in the client's voice, and push the whole lot into the Wix CMS through the API.

Then verify it. Record by record, field by field. That part isn't optional, and it isn't glamorous — AI is fast, not infallible, and a wrong flow rate on a pump page is worse than no flow rate.

Speed comes from the restructuring; trust comes from the checking.

That's the competitive edge, and it's worth being blunt about it: the manufacturer who can restructure their catalogue in a few weeks beats the one who's been "planning to sort the website out" for three years. Not because their pumps are better. Because a buyer can find them.

Your competitors' catalogues are stuck in PDFs because restructuring them used to take months. It doesn't anymore. That's the whole edge.

An assistant that knows the catalogue

Same structured data, second job.

Every technical sales team loses hours a week to the same conversation.

What are you pumping?

How thick is it?

What sector?

Good questions — but an engineer shouldn't be asking them by email at nine at night, twelve times a month, to work out that the answer was the SyQuick.

So we built a pump-selection assistant on top of the catalogue.

It asks what you're pumping, what you're doing with it, and what sector you're in. Then it names one product, says why in plain English, and hands you to the quote form. It recommends only from the real catalogue — it won't invent a model number or a flow rate. It won't quote a price. And anything unusual or safety-critical — explosive gas, extreme temperatures, odd chemicals — goes straight to a human.

Asked cold: abrasive sludge, 60% solids, wastewater. It named the Syflex peristaltic, explained why, and offered the G Range as the alternative.

Which, as it happens, is exactly what a good applications engineer does. That's not an accident; that's what we trained it on.

And it ends where it should — with an engineer.

The commercial point isn't the chatbot. It's that the easy 70% of enquiries get qualified before anyone picks up the phone — so the engineer's time goes on the specifications worth their time, and the buyer at eleven at night gets an answer instead of a contact form.

One thing worth flagging for anyone about to do this: Wix's AI site chat doesn't index dynamic pages. We'd just built 34 CMS-driven product pages and none of them were readable to it.

The fix was to hand the assistant the catalogue directly as a structured knowledge base, with every live URL in it. If you move a product range into a CMS, check this before you assume your chat can see it — and keep an eye on where Wix is heading with agent access.

Then there's the search problem coming for everyone

Buyers don't only search Google now. They ask an assistant. "Which pump handles 60% solids abrasive sludge?" And the answer comes back as a recommendation, not ten blue links.

You don't get cited in that answer by writing more blog posts — your Google ranking no longer buys you AI search visibility. You get cited by having product data a machine can actually read: clean fields, consistent naming, one page per product, and a plain-English description of what each product is for — not just its specs.

Most manufacturers' product data is a PDF.

PDFs don't get recommended.

The same work that makes the site navigable for a human is what makes it legible to a machine. That's the whole trick, and it's not really an AI trick at all. It's information architecture, finally being worth doing properly.

AI can't recommend a pump it can't read. Most manufacturers' product data is a PDF. That's the gap.

What we found in QA (and this is why you QA)

We crawled the build before launch and fetched all 63 unique internal destinations.

Zero broken links. Every product page, every industry page, HTTP 200.

And then: the "Request a quote" button — in the header, on every single page — pointed at the Information Centre. Not the contact form. The site's most important CTA was sending quote-ready buyers to a page of articles.

The link worked perfectly. It just went to the wrong place. Which is precisely the kind of thing that never shows up in a link check and quietly eats your conversion rate for a year.

Two more like it, both on primary conversion paths. The header CTA was repointed before launch.

Where it landed

The site's live at torqueflow-sydex.com.

The homepage a buyer lands on now.

• 44 database-driven pages from two templates, off two cross-referenced collections

• Navigation split by how buyers think: "I know my industry" / "I know my product"

• A 9-field quote form that asks for industry, fluid, flow rate and pressure — so the first call starts with a specification, not an introduction

• Clean slugs, unique metadata on every product and industry page

• A custom icon set, one design system, and a team that can add a product without calling us

• A pump-selection assistant that knows the catalogue

Nine fields. The first call now starts with a specification, not an introduction.

Audit in May. Live in July.

If your catalogue is the problem

If you manufacture or distribute a technical range and your website makes buyers work to find the right product, the fix probably isn't a redesign. It's a database.

And if your product data is trapped in PDFs and old pages, that's no longer the three-month job it used to be.

Drop us a line and tell us what you're selling — the contact page is the quickest way. We'll tell you honestly whether it's a structural problem or a design one. That's what the audit's for, and it's how every project here starts.

Maciej Konarzewski - Founder of Vis Marketing.

Free Website Consultation

20min

Book Now

---

FAQs

Why not just redesign the existing site?

Because the problem wasn't how it looked. It was that 42 pages had been built one at a time, with no template behind them — so every new product meant another page built by hand. That's not a fault of the original build; it's what happens when a range doubles and the structure stays still. A redesign makes it prettier. A CMS makes it stop.

How long does a rebuild like this take?

Torqueflow was audited in May and live in July. For a 40-odd page site with two databases, budget six to eight weeks from kickoff, assuming feedback comes back promptly. The template sign-off is the gate — everything waits on it.

Do we need to be on Wix already?

No. Torqueflow were on Wix Classic, which made the migration to Wix Studio cleaner — content and assets carried straight across. But the approach is the same whatever you're on: audit, agree the structure, build the templates, migrate the data.

Can our team add products afterwards, or do we come back to you?

Your team adds them. That's the point of the template system — a new product is a row in a database and the page builds itself.

How do you get a whole product catalogue into a database without it taking months?

AI does the restructuring — parsing specs out of existing pages and brochures into structured fields, mapping products to categories and industries, drafting metadata — and then it's verified record by record. Weeks, not months. The verification is the part that matters; AI is fast, not infallible.

Will an AI assistant on our site actually save us time, or just annoy people?

It saves time if it's built to qualify rather than to sell. Ours asks two or three questions, recommends one product from the real catalogue, and hands anything unusual straight to a human. That takes the repetitive "what are you pumping?" exchanges off your engineers and leaves them the enquiries worth their attention. Built badly — inventing model numbers, guessing at specs — it costs you more than it saves.

What does "AI search ready" actually mean for a manufacturer?

It means an assistant can read your catalogue and recommend your product. That needs clean structured data, one page per product, consistent naming, and plain-English descriptions of what each product is for. Most manufacturers' data is locked in PDFs, so they're invisible to it. Fixing the structure fixes both problems at once: buyers can navigate it and machines can cite it.