When engineers leave a product page without enquiring, it’s usually because they couldn’t find what they needed to take the product to their team: a clear statement of what it’s for, a readable spec table, the datasheet and CAD, the approvals, proof that it works, or answers to the obvious questions. Each of those can be fixed on the page itself.
A product page for a winch, a sensor, an ROV or a pump has a harder job than a product page for a pair of trainers. Nobody buys a subsea camera system on impulse. The page has to do what a salesperson and an applications engineer would do in a first meeting: explain what the product is for, prove it can do the job, and give the buyer what they need to take it to the rest of their team.
Most engineering firms we work with have the information. It’s in datasheets, manuals, test reports and the heads of the people who designed the kit. The problem is usually that the website only shows a fraction of it, often as a paragraph of marketing copy and a PDF link. If engineers visit your product pages but don’t enquire, or email to ask for things that should already be there, these are the usual causes. The fixes apply to most engineering, maritime and defence equipment.
Quick diagnosis
Why aren't your product pages turning into enquiries?
- Engineers leave the page within secondsThey can't tell what it's forSee the fix
- Enquiries just ask for the datasheetDownloads are hidden or gatedSee the fix
- Engineers email asking for specific figuresThe specifications are hard to readSee the fix
- Procurement asks for certificates by emailApprovals aren't listedSee the fix
- Sales answers the same questions every weekCommon questions aren't answeredSee the fix
- The page doesn't show up for the model nameSearch engines can't tell what it isSee the fix
Product pages
Anatomy of a product page for engineered equipment
The page should do the job of a first meeting with sales and an applications engineer.
- 1Name, one-line purpose, real photoWhat it does, where it's used and the limit that matters most.
- 2Two or three specific differencesMeasurable points, not “industry-leading”.
- 3Specification table in HTMLGrouped rows, consistent units, test conditions, revision date.
- 4DownloadsDatasheet, drawings, STEP files, manual, declaration of conformity.
- 5Approvals and standardsUKCA or CE, Red Ensign, class approvals, IP ratings, with certificates.
- 6In usePhotos on site, close-ups, dimensioned drawing, short video.
- 7Questions buyers askLead time, spares, rental, training, integration, modifications.
- 8One clear next stepMatched to how the product is actually sold.
They can't tell what it's for
The first sentence under the product name should tell a buyer what the product does, where it’s used, and the one or two limits that matter most. For example: “A compact inspection-class ROV for hull, tank and harbour inspection, rated to 300 m.” A buyer can decide from that line alone whether to keep reading.
Put the main image next to it, and make it a real photo of the product, not a render floating on a white background, unless the product doesn’t exist yet. Then two or three short points on what makes it different from the obvious alternatives. Keep them specific and measurable.
Rewrite the key points
Examples for illustration. Use figures you can back up.
Detail is held back because nobody checked what can be published
If you work in defence or dual-use technology, some products and some technical detail may be subject to export controls. Publishing a detailed spec for a controlled product isn’t always straightforward, so check with whoever handles export compliance before you write the spec table, not after the page goes live. The Export Control Joint Unit is the UK body that administers strategic export licensing. The same applies to customer names and application examples, which may need the customer’s permission.
The specifications are hard to read
In our experience the specifications are the first thing engineers look for on a product page, and they’re often the worst presented. Too many sites put them in an image, or only in the PDF datasheet. Use an HTML table instead. It loads faster, it works on a phone, it can be copied into a comparison spreadsheet, it can be read by a screen reader, and search engines can index it.
Group the rows so people can find what they need, keep the units consistent, state the test conditions where they matter and show a revision date. A depth rating or battery life means little without the conditions it was measured in. If you sell into the US, give imperial in brackets alongside metric.
Specification
Inspection-class ROV
| Dimensions | |
|---|---|
| Length x width x height | 535 x 390 x 290 mm |
| Weight in air | 15 kg |
| Performance | |
| Depth rating | 300 m |
| Forward speed | 3 knots |
| Test conditions | Seawater, 10 °C, 1 kn current |
| Power and interfaces | |
| Supply | 110 to 240 V AC |
| Tether | 300 m, neutrally buoyant |
| Video output | HD-SDI and IP |
The downloads are hidden or gated
Engineers want the datasheet, the dimensioned drawing, the 3D model (usually as a STEP file), the manual and the declaration of conformity. Put them in one clearly labelled section with the file type and size next to each one. Name the files properly, so “ACME-X200-datasheet-rev3.pdf” and not “document(4).pdf”, because they’ll end up in someone’s downloads folder alongside a dozen others.
Think carefully before putting a form in front of the datasheet. It will get you some email addresses, but it also stops a lot of engineers at the exact point they were getting interested. Many firms leave datasheets open and ask for details only for CAD files or detailed technical documents, which is a reasonable middle ground.
Approvals and standards aren't listed
Say which standards the product meets and which approvals it holds, and link to the certificates. For products sold in Great Britain that usually means UKCA or CE marking, and for marine equipment going on UK ships, the Red Ensign mark. The government’s product marking guidance sets out which mark applies to which type of product. Add any class type approvals, IP ratings and relevant test standards. Procurement teams usually check these early, so don’t make them hunt.
There's no evidence it works
Photos of the product in use do more than any amount of copy. On a vessel, in a workshop, in a test tank, being handled by the people who’d actually use it. Add a dimensioned drawing, and close-up photos of connectors and controls, because those are the details engineers want to check. We cover this in more detail in things to consider before filming a new product.
Give every image a descriptive file name and alt text that says what’s in it. Google’s image SEO guidance explains why this matters for search, and it matters for accessibility too.
For equipment that works somewhere a camera can’t easily go, or where the interesting part is inside the housing, a short 3D animation or motion graphic can explain it more clearly than photography.
Their questions aren't answered
Ask whoever handles enquiries what they get asked every week, and answer those questions on the page. Lead times. Whether spares are held in stock. Whether it can be rented rather than bought. What training is included. What it integrates with. Whether you can modify it for a particular application. A short list of questions and answers near the bottom of the page saves everyone time, and it answers the same questions buyers type into search engines. Keep each answer to a line or two. “Standard units ship in four to six weeks” is more use to a buyer than “contact us for lead times”.
If you sell a range, a comparison page with the key figures on each model helps buyers narrow it down before they open a single product page.
Finish with a clear next step that fits the product. For a catalogue item that might be a quote request. For a system that’s configured to order, it’s more likely a call with an engineer.
Search engines can't tell what the product is
Product structured data is code in the page that tells search engines the product’s name, brand, model number and so on. Google’s product structured data documentation explains what’s supported. Some of the richer search results need a price or reviews, which many B2B products won’t have, but marking up the basics is still worthwhile. It sits alongside the normal SEO work of giving each product a clear title and description, and making sure each one has its own page rather than sharing one long page with the whole range.
Common questions
What should a technical product page include?
A one-line description of what the product does and its key limits, real photos, a specification table in HTML, downloads (datasheet, drawings, CAD, manual and declaration of conformity), approvals and standards, examples of it in use, answers to common questions and one clear next step.
Should datasheets be behind a form?
Usually not. A form in front of a datasheet stops many engineers at the point they’re getting interested. Many firms leave datasheets open and ask for contact details only for CAD files or detailed technical documents.
Is product schema worth adding if we don’t show prices?
Yes. It helps search engines understand the product’s name, brand, model and images. Some of Google’s richer product results need a price or reviews, but marking up the basics is still worth doing.
Where to start
You don’t need to rewrite every product page at once. Start with the products that bring in the most revenue or the most enquiries, get those right, and use them as the template for the rest. If your site’s overall structure needs work too, our post on getting more from your maritime website covers the wider picture.
We did this kind of work for Colourvoid, an international security manufacturer, where we built a bilingual English and Portuguese site with detailed product information and new photography and video, and more recently for Atlantas Marine‘s own ROV and camera product lines as part of their website rebuild. If you’d like a hand with yours, get in touch.
