Manufacturer websites
A manufacturer's website has the opposite problem to a shop's. No cart, no prices, no impulse purchase. There is an engineer, a buyer or a design consultant looking for a specific parameter, and if they do not find it in text they move on to the next supplier. The search volumes are small, but any one of them can be the start of a contract that runs for years.
In short
- General search terms and specific parameters are not mutually exclusive: general terms lead to a category, specific parameters and part numbers to a product group or item page.
- The most valuable content is what competitors do not publish: tolerances, production limits, lead times, compatible models, the common mistake when ordering.
- A PDF catalogue is not invisible - Google indexes PDFs and they can rank. The difference is convenience: separate pages are easier to browse, update and enquire from.
Table of contents
- Why the logic is different here
- Who searches and what they type
- Parameters and general search terms
- The PDF catalogue: what is actually lost
- How the site is organised
- The product group page
- Made to order
- Trust over a long cycle
- The path to an enquiry in B2B
- When you sell through distributors
- Export and a second language
- How to measure at low volumes
- Common mistakes
- Frequently asked questions
Why the logic is different here
In an industrial business, success is not traffic but a handful of the right visits each month. Ten enquiries from engineers selecting a supplier are worth more than three thousand visits from people browsing.
Three differences from a consumer site
- Searching is often by parameter rather than by benefit: size, material, rating, standard.
- The decision is taken by several people over weeks or months.
- Price is rarely public, but lead time, minimum batch and the option of making to drawing can be.
On the competition
The general impression from the projects we have worked on is that competition on narrow technical queries is weaker than in consumer niches: a large share of manufacturer sites consist of a home page, an about page and a catalogue to download. That is an observation, not a measured quantity - for your own niche it is tested with a specific analysis of the top ten results on several of your parameters.
If your page does not exist, the engineer does not abandon the search. They find another supplier. The difference between you and them is sometimes not the quality of the product but the presence of a table in HTML.
Who searches and what they type
At least three roles search around one industrial solution, and each writes differently. A site built for only one of them loses the others.
| Role | What they look for | What they need to find |
|---|---|---|
| Engineer or design consultant | Parameter, standard, compatibility | Specification table, drawing, tolerances |
| Buyer | Lead time, minimum batch, terms | Timeframes, how to order, documents |
| Manager or investor | Reliability, capacity, references | Completed projects, certificates, capacity |
| Maintenance technician | Spare part, consumable, diagram | Compatible models, part numbers |
Who starts the search
Usually the engineer or the technician, that is, whoever searches by parameter. They draw up the shortlist, and the buyer then checks timeframes and prices only within that shortlist. So the technical search is the entry point to the commercial stage.
The maintenance technician types a part number, a machine model or a description of a symptom. Those are the narrowest and most purchase-ready queries in the niche. A list of compatible models and part numbers is rarely found at competitors.
How to find out what yours type
Go through the queries in Search Console for the past six months and pick out those containing a number, a size, a standard or a model. That is the real map of demand in your case. In parallel, ask your sales people what questions come in by phone: the same questions get typed into Google.
Parameters and general search terms
A clarification is needed here, because this is often presented as a choice between the two. It is not a choice. "Steel structures", "industrial batteries" and "packaging" are perfectly sensible searches with real volume. They simply call for a different type of page.
| Type of query | Suitable page |
|---|---|
| industrial batteries | Category: what types exist, how to choose between them |
| 48V traction battery for a forklift | Product group page with a table |
| a specific model or part number | Its own product page |
| how to choose a traction battery | An article leading to the category |
Low volume is not a problem in itself. A query with twenty searches a month and real purchase readiness is worth more than one with two thousand from the curious. The sum is done on customer value, not on search volume.
How these queries get collected
- List the parameters orders actually come in by.
- Combine them with product names as customers write them, not as your internal catalogue has them.
- Check in Search Console and the planning tool whether they are searched.
- Group them by product group.
- Build a group page covering the whole parameter table.
When a group page is not enough
One page per group works when the variants differ only by values in a table. When items have different applications, different standards or their own part numbers, a separate product page is justified even without recorded volume for that exact model: the technician searching by number has to arrive at something specific. The opposite extreme - a hundred thin pages for every parameter combination - does not work either.
The PDF catalogue: what is actually lost
The common claim is that PDFs do not rank. That is not true: Google indexes PDF files and they can appear in results, including on narrow technical queries. The difference is not visibility but convenience - for browsing, for updating and for getting to an enquiry.
What is actually lost
- A single document rarely gives each product group its own context: applications, lead times, compatibility. Technically possible, but catalogues are built on a different logic.
- Navigation inside a PDF is poorer: links and contact details can be embedded, but moving between groups, projects and spare parts is clumsier than on a web page.
- A path to an enquiry from the point where the person found the parameter is usually absent.
- The file often opens straight in the browser, but it is still heavier to browse than a table on a page, especially on a phone.
- Updating one parameter requires a new file, so catalogues go stale faster than pages.
What to do instead
Keep the catalogue, but do not let it be the only carrier. Publish the same data as an HTML table on the group page, with clear column headings, units and a column for availability or lead time. The download stays for those who attach it to a project.
You can also see which queries the PDF itself appears for: when a document shows in results, its URL appears in the pages report and the queries to it are visible. So a PDF is not a blind spot in the data, though it is more awkward to work with than separate pages.
Drawings stay as images or files, but the dimensions from them are written out as text as well. The same goes for wiring diagrams and overall dimensions. One rule covers it: if somebody might search for that number, it has to be in text.
How the site is organised
The structure follows how the customer thinks about the products, not how the production catalogue is arranged.
The levels
- What we make: a list of product groups, intelligible to an outsider.
- Category: what types exist, how to choose between them, who each suits.
- Product group page: full parameter table, applications, lead times, how to order.
- Product page: where an item has its own number, standard or application.
What runs alongside
- A page on capacity and equipment: machines, tolerances, materials worked.
- Completed projects with real parameters, not just photographs.
- Certificates and standards worked to, listed as text.
- A company page with data that stands up to checking.
- A path to an enquiry from every technical page.
Groups are named in the customer's words. If your catalogue calls an item "profile type 4B" while customers search for "aluminium door threshold", the heading carries the second and the first sits in the table.
A distinction is needed here. Unfamiliar internal designations bring no search, because nobody outside the company knows them. Product numbers, however, do: the customer often knows the code from an old catalogue, from documentation or from an item already bought, and searches for exactly that. So catalogue and batch numbers are worth having in text and searchable on the site, even when the heading is in the customer's language.
For internal linking: every group page leads to the applications and the projects using that item, and the projects lead back to the groups. The logic of linking between a main page and its supporting pages is covered in the article on the pillar page.
The product group page
This is the page doing the main work. If you get only this one right, the rest can wait.
The mandatory minimum
- A heading with the product name as customers search for it.
- Two to four sentences: what it is, what it is used for, who orders it.
- A parameter table: sizes, materials, ratings, tolerances, weights, with units in the headings.
- Applications: which sectors and for what tasks.
- Standards and certificates relevant to that item.
- What is in stock and what is made to order, with indicative lead times.
- Minimum batch, if there is one.
- What is needed for a quote: drawing, quantity, timeframe, delivery.
- Photographs of the actual item, not stock images.
- Links to related groups and to projects using it.
What makes it the best page on the subject
The information competitors do not publish: tolerances, what cannot be made, the typical mistake when ordering, what affects the lead time, when new tooling becomes necessary. That is shop-floor knowledge and it does not get copied from someone else's site.
When structured markup is also worth it
For an item with stable characteristics and its own page, Product structured data helps the description be read unambiguously. A clarification is needed: valid Schema.org description and eligibility for a Google product rich result are different things. For the latter, Google requires name plus at least one of offers, review or aggregateRating. If you publish no price and have no reviews, the markup remains useful for clarity but a rich result should not be expected. The requirements are in Google's documentation on product snippets.
What not to write
Do not list standards you do not work to, or certificates that have expired. In this niche the customer checks, and one discrepancy can stop the conversation. The same applies to capacity and lead times: a real timeframe beats a promised one.
Made to order
Most manufacturers do both standard items and work to drawing. The second is rarely explained well on the site, and it is what brings the larger projects.
What the customer wants to know
- The limits you work within: sizes, materials, weights, tolerances.
- What you need in order to start: drawing, sample, specification, in what format.
- How long a quote takes and how long production takes.
- Whether there is a minimum quantity and what happens with one-offs.
- Who handles the design work if there is no drawing.
- How things are confirmed before a production run: sample, report, measurement.
This belongs on its own page rather than in a paragraph, because it is a separate service with its own search: "made to drawing", "non-standard item", "part to sample". A paragraph on the home page does not catch those.
What is rarely stated and works
What you cannot do. A limit such as "up to 6 metres in length" or "we do not machine titanium" saves time on both sides. A manufacturer who states their limits comes across as more competent than one claiming to do everything.
Trust over a long cycle
An industrial order carries risk: a supplier who fails can stop a production line. So trust gets checked more carefully than in any consumer purchase.
What actually gets checked
- Whether the company has existed for a while and operates continuously.
- Whether there are similar projects by size and complexity.
- What capacity it has and whether it will hold up for the run.
- What certificates and standards it works to.
- Who the contact will be and whether there is a technical contact.
- What happens in the event of a complaint.
References get shown not as a row of logos, but with real parameters: what was made, in what quantity, over what period, to what requirements. If a client does not allow being named, describe the project without the name: "food producer, 400 items, six-week lead time". That is more convincing than twenty logos with no context.
Why company data is part of the sale
Checking a supplier starts with a search on the company name. What gets found then, including by automated checks, is covered in the article on the Search Console queries that ask about your company. Our own completed work is on the projects page.
The path to an enquiry in B2B
Here an enquiry is a request for a quote and needs a different form from a consumer one.
What has to be possible
- Attaching a file: drawing, specification, photograph of a sample.
- A field for quantity and for the desired timeframe.
- A choice of whether it is a one-off or a production run.
- A direct number for a technical contact, not only a general one.
- An email address visible as text.
These fields are not superfluous: on a technical request they save a whole round of clarifications and improve the quality of enquiries. Administrative details, however, get collected at the order stage, not the enquiry stage: registration numbers and registered addresses only put people off here.
The phone matters more here than on a consumer site. An engineer with a specific question about a tolerance would rather call. If the site offers only a form, they call the competitor who published a number. This is one of the most underrated changes on industrial sites.
What gets measured besides enquiries
A downloaded specification, a visit to the projects page, a click on the phone number, a return visit days later. On a cycle measured in months, those are the real intermediate signals. How they fit into measurement is covered in the article on where people drop off between click and enquiry.
When you sell through distributors
Some manufacturers do not sell directly and conclude that their website is not a commercial tool. The opposite is true.
What the site does in this model
- The end user searches by parameter, reaches you, and you direct them to a distributor.
- The technician searches for a spare part and finds the number at your site.
- A new distributor finds you and asks about terms.
- A design consultant writes your item into a project specification, and whoever executes that project then has to source it.
What it needs to have
A list of distributors by region with contact details, a page on terms for becoming a distributor, and technical information accessible without registration. Requiring registration for specifications means the data itself stays out of the index, and the engineer who does not want to create an account goes to a competitor. If something needs protecting, protect the prices, not the parameters.
Why the design consultant is an important role
Because once your item is named in the project documentation, every build to that documentation has to use it. An item written into a specification can bring orders for years. Design consultants search by standard and by parameter, which is precisely what a large share of manufacturers do not publish.
Export and a second language
If you export or want to, a second language is not a translation of the home page.
What gets translated first
- The product group pages with their full tables.
- The page on capacity and equipment.
- The page on work to drawing.
- Certificates and standards.
- Contacts, stating who speaks which language.
News, company history and the blog come last: useful, but they do not bring the technical search.
Partial translation is normal
A misconception circulates that both language versions must have the same number of pages. They do not. A partially translated version works perfectly well, provided the links between language versions point only to genuinely corresponding pages. A page with no counterpart simply does not take part in the pairing. What breaks when a language is added to an existing site is covered in the article on redesign without losing traffic.
On units and standards: in the other language, standards are written with their international designations. The same for units: if the niche uses inches, give them in a separate column.
How to measure at low volumes
| Do not look at | Look at |
|---|---|
| Total visits | Number of technical queries you appear for |
| Bounce rate | Downloaded specifications and phone clicks |
| Site-wide average position | Positions on specific technical queries |
| Monthly conversion rate | Absolute number of enquiries and the share becoming projects |
On the period: a quarter beats a month, but at two or three enquiries a month even a quarter is not enough for a reliable comparison. At those volumes, work with absolute numbers and a direction over six to twelve months rather than percentages. A difference between two and four enquiries is not a trend.
The most useful report is a list of queries containing a number, a size or a standard, with position and impressions. It shows which parameters already find you and which are missing from the site. That is also the working list for the next pages.
When results show
Technical pages with real data on low-competition queries can rank quickly, because competition there is thinner. Broad phrases stay difficult and call for separate work on the category pages. Ongoing technical monitoring is a separate task and is covered by the monitoring service.
Common mistakes
A home page that talks about the company
"Founded in 1994 with a mission for quality" answers no search. The home page says what is made, for whom and within what limits.
All the technical data behind a login
The data stays out of the index and the engineer goes to a competitor. Protect the prices, not the parameters.
One page for all products
A single "Products" page with a gallery of twenty photographs gives no group its own context.
Internal designations instead of the customer's language
Headings taken from the internal catalogue are invisible to search. The code stays in the table.
No number for a technical contact
A general number and a form are not enough for a technical question. Direct contact with someone who can answer on a tolerance speeds things up more than any other change.
A site that does not work on a phone
The technician checks a part on the shop floor, from a phone. A table that cannot be read on a small screen is a lost enquiry. How real-world speed gets measured is covered in the article on Core Web Vitals from the real user's perspective.
Expecting the site to do everything
An industrial site rarely brings an order on its own. It gets you onto the shortlist and prepares the conversation: that is its job, and it is enough. If you would like it organised for your own production, start with the contacts page or see what website development covers.
Frequently asked questions
Is SEO worth it if queries in my niche run at twenty a month?
It depends on the profit per order, not the turnover. Twenty searches from engineers selecting a supplier can be worth more than two thousand from the curious. The sum is: expected number of enquiries, times the share that become projects, times profit per order, not order value. Turnover on its own proves nothing, because production costs can absorb the difference. If the result covers the cost of the content several times over, the work is worth it.
Do I have to publish prices if every quote is individual?
Prices are not essential, but lead times, minimum batches and production limits are worth publishing. An industrial buyer does not expect a price on the website, but does expect to understand whether you can fulfil the request at all. Without those limits they may drop out before enquiring, because they do not want to spend time on a conversation that may be pointless.
Why is a PDF catalogue not enough?
Not because it is invisible: Google indexes PDF files and they can rank. The difference is convenience. A catalogue rarely gives each product group its own context and a path to an enquiry from the point where the person found the parameter, it is heavier to browse on a phone, and updating one parameter requires a new file. Keep the catalogue, but publish the same data as an HTML table as well.