The spec sheet as a web page: writing for people who already know
A process engineer has a failed unit, a shutdown window that closes on Saturday, and a phone. He is standing in a plant room and he needs three numbers from you: the duty, the physical envelope, and whether the connections match what is already bolted to the floor. If your website gives him those in under a minute he will call. If it gives him a 6MB download, he will go back to the search results and open somebody else.
That is the whole commercial case for treating the spec sheet as a web page rather than as an attachment, and it is not really a design argument. It is an argument about where the information physically is at the moment somebody needs it.
Most Singapore manufacturers and equipment suppliers we look at have the data. It exists, it is accurate, engineers inside the business know it by heart. It is just sitting inside a file rather than on a page, which means it is invisible to search, awkward on a phone, unreadable to assistive technology, and quietly out of date in a hundred people’s downloads folders.
What is a technical buyer actually doing on your product page?
Not reading it. Scanning it for parameters, in the same way you would scan an aircraft departure board.
This is not a slight on your prose, it is how everyone uses the web. Nielsen Norman Group’s analysis of 45,237 page views concluded that on an average page, users have time to read at most 28% of the words during a visit, and that 20% is the more likely figure. Their other finding from the same dataset is the one worth pinning above a copywriter’s desk: users read half the information only on pages of 111 words or less.
A technical buyer is a harder case than that average, because they arrive with a specification in their head and a comparison to make. They are not evaluating you, they are matching values. Flow against required flow. Tolerance against drawing tolerance. Voltage, phase, footprint, flange standard, temperature range, certification. Everything on the page that is not one of those values is friction between them and the answer.
So prose is the wrong container. A paragraph explaining that your unit “delivers exceptional performance across a wide range of demanding applications” costs the reader time and returns nothing, because it holds no number they can compare against. A table with the range in it, and the conditions that range was measured under, answers the question and ends the visit in the good way.
It also means you should stop explaining. Your reader knows what a duty cycle is. Writing for someone who already knows is a different craft, and the main difference is how much you are allowed to leave out.
Why the specification is still a PDF
Because it used to be a printed page, and nobody made a decision to change that.
The datasheet is one of the oldest documents in industry. It was a sheet, then a photocopy in a ring binder, then a fax, then a PDF, because a PDF preserved the layout exactly and could be emailed. Every one of those steps was sensible at the time. The last one has stopped being sensible, because the place buyers now look is a search box, not an inbox.
There is a second reason, and it is organisational. The PDF is usually made by whoever produces the print collateral, and the website is usually run by somebody else. Publishing the specification as a page means the two have to agree on a source of truth. Uploading a file to a downloads section means nobody has to agree on anything. So the file wins by default, year after year, and the website ends up as a shelf for documents rather than a place where information lives.
You can see the end state of that in the field. Across 54 Singapore B2B sites we reviewed in August 2026, 19 published no project record, portfolio or case studies at all, and the pattern in the technical sectors was consistent: the one page a buyer actually came for was missing, stale, or contradicting itself. One listed shipping company’s fleet page claimed 16 vessels while its own services page claimed five management agreements. One crane rental business had a single loading page describing its fleet as at December 2009, with 88 cranes and 213 aerial lifts. One precision engineering firm holding AS9100D had a news link returning HTTP 500 and a downloads section whose current brochure was the 2018 file.
None of those companies is careless about equipment. They are careless about the document that describes it, because the document sits outside the system that anyone maintains.
What burying the specification in a PDF costs you
It is a worse result in search
Google will index it. Its documentation lists PDF among the encoded file types it can parse, describing them as binary files or complex containers that need a specific parser to extract human-readable text.
Indexed is not the same as competitive. A PDF carries no structured data, because Google’s structured data is markup on a web page. It has no internal links into the rest of your site, so it earns nothing for the pages around it. It usually duplicates a product page that already exists, so two of your own URLs compete on the same terms. And what a searcher sees in the results is a file with a filename, which is a less attractive click than a page.
The same problem shows up in AI answers. Whether an assistant can quote your specification depends on whether it can parse the values cleanly and attribute them to a stable URL. A marked-up table on a page is an easy thing to lift. A rasterised table inside a PDF is not, and a scanned datasheet is nothing at all.
It is unreadable in the place it is most often opened
A PDF laid out for A4 does not reflow. On a phone it becomes a pinch-and-zoom exercise, which is exactly the wrong interaction for someone holding the phone in one hand in a plant room, or on a vessel, or in a car park between site visits. Nielsen Norman Group has been publishing the same finding about PDF and on-screen reading for over two decades, and the arrival of the smartphone made it considerably worse rather than better.
It is the least accessible format you could have chosen
This is the part most companies have never looked at. A 2026 analysis of 69,944 PDF documents published on German public sector websites found that only 9.5% passed the PDF Accessibility Checker and 37.4% were not tagged at all. Those are organisations under an explicit legal duty. Commercial manufacturers are not doing better.
An untagged PDF has no reading order. A screen reader receives characters in the order they were drawn onto the page, not the order a person reads them, which turns a two-column datasheet into a shuffled deck. Tables lose their structure entirely, so the value in a cell arrives with no idea which row and column it belongs to, which for a specification destroys the only thing that mattered.
Accessible PDFs are possible. The W3C publishes PDF techniques for WCAG and the tooling exists. The honest question is whether your marketing coordinator is going to tag every datasheet correctly every time, forever. A properly marked-up HTML table gets this right by default.
It goes stale invisibly
The moment somebody downloads your datasheet, they own a private copy of it, and you have lost the ability to correct it.
That copy gets attached to a tender submission. It gets saved into a project folder. It gets forwarded to a consultant who files it and refers to it eighteen months later. If you revise a tolerance, supersede a model, or change a supply option, none of those copies change with you, and the first you hear about it is a dispute over what was specified.
A page has the opposite property. Correct it once and every future reader gets the corrected version. Date it, and a buyer can see how current it is without asking.
It ends the visit
A PDF is a dead end by design. No enquiry form, no link to the next model up, no route to a person. The reader leaves your website to open it and frequently does not come back.
You also learn nothing. A download is not a read. You cannot tell whether they reached the last page, whether they were comparing two models, or which parameter made them stop. On a page you can see all of that, and it tells you what to publish next.
What belongs on a specification page
Write it for the person doing the matching, in the order they match.
The identifier. Model or part number exactly as it appears on the nameplate and in procurement documents, including variant suffixes. This is the single most searched string associated with your product and it should be text on the page, not part of an image.
Physical envelope. Dimensions, weight, footprint, mounting arrangement, and the service clearances required around it. The last one is left out constantly and is often the reason a unit gets rejected.
Performance, with conditions. Capacity, duty, flow, head, pressure, throughput, accuracy, tolerance, rating. Every figure carries the conditions it was measured under. A tolerance with no material and no temperature stated is not a specification, it is a hope.
Connections and supply. Voltage, phase, frequency, power draw, port sizes, thread or flange standards, communication protocols. This is the detail that decides whether your unit drops into an existing installation.
Limits. Operating temperature range, ambient conditions, ingress protection, duty cycle, maximum continuous rating. Say plainly what the product is not suitable for. Buyers trust a stated limit more than a page of claims, and it saves you the enquiries you were never going to win.
Standards and approvals, with scope. Which standard, which edition, which certifying body, and what the certificate actually covers. A logo strip is decoration. A named standard with its scope is evidence, and it is what gets copied into a prequalification form.
Options and availability. Which variants exist, which are stocked, which are made to order, and an honest lead time band rather than a single number you will miss.
Support life. Spares, consumables, service intervals, and how long parts remain available. For capital equipment this is frequently the deciding factor and it is almost never published.
Files that engineers actually want. Dimensional drawings, DXF or STEP models, installation manuals. These are legitimate downloads, because a CAD model is meant to be a file.
A named technical contact. Not a form. Someone with a name who can answer a question about a value on this page.
How to structure it
One page per product or model. Not one page listing forty products, and not a category page with a table of links to PDFs. A specific URL for a specific model is what search can rank, what an assistant can cite, and what a buyer can paste into an email to a colleague. Choose the URL carefully and keep it through your next redesign, because links to it are an asset.
Real tables, real headings, real text. Header cells for the parameter names, units in the header rather than repeated in every cell, and no images of tables. If a value can be selected and copied, it can be indexed, translated, read aloud and quoted. If it is a picture, it is none of those things.
Group by decision, not by department. The order above follows the sequence of a buyer’s elimination process. Marketing copy, if you want any, goes under the table rather than in front of it.
Date and version the page. A visible “specification current as of” line does two jobs: it tells a buyer the data is maintained, and it tells you which pages have gone quiet.
Cross-link the range. Every model page should link to the models either side of it and to a comparison table for the whole range. A buyer who has landed on the wrong model should be one click from the right one.
Keep the PDF, and generate it from the page. Buyers submitting into an approval file or a tender still need a document, and refusing to give them one is stubbornness rather than strategy. The rule is direction of travel: the page is the source, the PDF is produced from it, and it carries the same version date. Then the two can never disagree, which is the actual failure mode you are trying to eliminate.
Where to start
This is a content problem before it is a design problem, and the first move costs nothing.
List every product or model you sell. For each one, check three things: does it have its own page with its own URL, are the specification values text rather than an image or a download, and what is the date on the newest thing about it anywhere on your site. Most companies find that the majority of the range is represented by a single PDF from several years ago, and that the values in it were correct when it was made.
That gap is the brief. The work is mostly extraction, getting numbers out of the heads of the people who know them and into a structure, and it is the part clients underestimate most and benefit from most.
It is the same logic behind the sites we build for technical clients. Towa Marine, who repair and install marine air-conditioning, ventilation, refrigeration and cold room systems across Singapore, Port Klang and Tanjong Uncang, lead with the systems and a 24 hour response commitment rather than with company history, because a superintendent should not have to scroll to find out whether the yard can help. THK Engineering presents electrical, ACMV, fire protection, plumbing and sanitary and ELV as one package rather than five services, because that is the shape of the question being asked at tender. We have written more broadly about web design for industrial companies in Singapore and the same pattern runs through all of it.
Projects start from S$4,000 where the technical content already exists in usable form, and what moves the number is how much of it has to be gathered, verified and structured from scratch. Our pricing bands are published rather than quoted on request, and every web build includes 30 days of post launch support so that the first round of corrections to a new specification page does not become a separate conversation.