How I build manufacturer websites.

This is the long-form view of how I approach a manufacturer website project. Every project flexes to fit the business in front of me, so this isn't a rigid template — but the principles below show up in almost every build I do. If you're considering working together, this is the read that gives you a feel for whether the approach lines up with what you're after.

1. Who this is for

This way of working is built for SME manufacturers and industrial B2B businesses — typically A$4M–A$100M turnover — where the website is going to do real commercial work rather than sit there as a brochure. Machine shops, fabricators, component makers, equipment builders, processors, distributors of engineered product. The common thread is a considered, technical purchase: a buyer with a spec, a drawing or a duty requirement, building a shortlist before they ever make contact.

It works whether you sell to OEMs, to trade, or direct to consumers — the channel isn't the point. What matters is that someone has to be convinced you can actually make the thing, to the tolerance, in the material, to the standard, in the time.

It's probably not the right fit for businesses outside manufacturing and industrial B2B — everything here is tuned to one buyer, and a generalist studio will serve a café or a clinic better than I will. It's also not the right fit for anyone shopping primarily on lowest price (there are good template-based options at lower price points, and that's the honest call in that scenario), or for enterprise organisations needing an agency with multiple disciplines under one roof.

If you're somewhere in the middle, a 15-minute discovery call is the cleanest way to figure out whether the fit is there. No pressure, no upsell.

2. The discovery phase

Every project begins with structured discovery before significant design or development effort goes in. For some projects this is a couple of weeks of dedicated workshopping; for others, where the brief is already clear and the owner is decisive, it moves faster. The shape stays the same — the time taken flexes with the project.

Discovery produces three things:

1. The marketing brief — who your buyer actually is, what they search and ask before they shortlist, where current enquiries come from, what's worked or failed in the past, and what the next 18 months need to look like. Usually 5–10 pages once it's finished.
2. The capability and site map — every process, material, tolerance range and application worth its own page, what each page is trying to make the visitor do, and where the friction sits in the current enquiry flow.
3. The visibility baseline — what you currently rank for, what you should rank for, and how often ChatGPT, Gemini and Perplexity name you when a buyer asks who to use. That last one is measured with Periscope, and it's usually the number that lands hardest.

At the end of discovery, you have a brief in hand. If at that point you decide the website isn't actually the right next step — maybe brand work needs to come first, maybe a content programme without a rebuild — you walk away owing only the workshop fee, and the project deposit is refunded in full. The discovery is honest work whether or not it leads to a build.

3. The build approach

The platform decision happens during discovery, based on what the project actually needs — not on what I default to in the abstract. The discovery brief makes the recommendation explicit and explains the reasoning, so there are no surprises later.

Broadly, the options break into three categories:

• Modern static frameworks. Fast, lean, very low long-term maintenance burden. Editing happens through a defined process rather than a self-serve dashboard — better for some businesses, worse for others. My usual recommendation for capability-led manufacturer sites, where a deep, well-structured content mesh and reliability matter more than self-serve editing.
• Hosted commerce platforms. When the project is genuinely an online store, a properly-built theme on an established commerce platform is almost always the right call. Trying to roll your own e-commerce on a non-commerce stack ends badly.
• A custom trade portal, integrated with your ERP. The bigger end of the work. When your customers still phone or email their orders in, the answer usually isn't a nicer catalogue — it's a logged-in portal showing their contract pricing, their order history and live stock, with orders flowing straight into NetSuite, Global Shop or Epicor. This is quoted to scope and it's a systems project, not a website project with a login bolted on.
• WordPress. Sometimes the right tool. Particularly when the project needs deep CMS workflows, complex content authoring, multi-author editing, or sits inside an existing WordPress ecosystem you already maintain. I'm happy to recommend it when it genuinely fits the brief — it just isn't my default for a technical manufacturing site.

A few practical things worth knowing about up front, because they shape the recommendation:

• Editing model. Some platforms put you in the driver's seat for content updates; others put a developer in that seat. Both have trade-offs — self-serve is faster but more error-prone, developer-led is slower but cleaner. We'll match this to how you actually want to maintain the site.
• Maintenance posture. Some stacks need active ongoing care (security patches, plugin updates, version bumps); others are largely set-and-forget. The right answer depends on whether you have, or want, someone responsible for ongoing maintenance.
• Performance ceiling. Lighthouse 95+ on mobile is achievable on any platform if it's built well — but some stacks make it dramatically easier to hold that line over time than others.

If you have a strong preference on platform when we get to discovery, we'll talk through the trade-offs and either align on it or have an honest conversation about why I'd push in a different direction. The platform recommendation is never the headline of the project — the result is.

4. The copy framework

A lot of websites that look great still don't convert, and it's almost always the copy. I draft copy before design starts, not after. The discipline is the same on every project: every page gets written in plain text first, in a shared document, with you. Design then follows the copy.

For capability pages I work to a three-paragraph structure:

1. The job the buyer came with. Named explicitly, in their language, not yours — the part, the material, the tolerance, the volume. By paragraph one the reader should be thinking "they do exactly my kind of work."
2. What's distinct about how you do it. Not features. Not adjectives. The specific machine, process, certification or decision that makes your version different from the next supplier on the shortlist.
3. What the next step is. One clear action — usually send a drawing or request a quote. Not three competing CTAs.

For homepage hero copy, the working pattern is: what you make → who you make it for → the proof → the next step. Generic hero copy gets stripped out — if a sentence could appear on fifty different manufacturers' sites, it doesn't earn its place on yours. "Quality products, competitive prices, excellent service" describes nobody.

The specifics are the whole game. A technical buyer skim-reading four supplier sites is looking for numbers: envelope sizes, bar capacity, tolerance bands, materials, certifications, lead times. Every one of those you publish is a reason for the right buyer to stay and the wrong one to leave — and both of those are wins. Vagueness reads as inexperience, and it gives the AI assistants your buyers now ask nothing concrete to recommend you for.

5. Found by Google and AI, from day one

"We'll do SEO after launch" is a common framing, and it usually means the real foundation never gets laid. Most of the work that matters is structure and copy decided during the build — not a separate engagement layered on three months later.

There's a second reason it can't wait. A growing share of your buyers now open ChatGPT, Gemini or Perplexity and ask who to use before they open a search results page — and an assistant can only recommend a supplier whose capabilities it can actually read and verify. A site that says "precision engineering solutions" gives it nothing to work with. A site that says what you machine, in what materials, to what tolerance, to what standard, gives it everything.

What gets done as part of every build:

• Keyword and buyer-question research, as part of the discovery brief
• A page per real capability — process, material, tolerance, application — so you're findable for the specific work you want more of, not just your industry's broadest term
• Page titles, meta descriptions and H1 hierarchy locked at the copy stage
• Schema markup where it earns its place (Organisation, Service, Product, FAQPage and similar), so machines can parse what you do rather than infer it
• Genuine answers to the questions buyers actually ask, published as content an assistant can quote
• Image alt text written deliberately, not auto-generated
• Open Graph and social card meta on every page
• XML sitemap generated and submitted to Google Search Console
• Canonical URLs locked, redirects mapped from any old domains
• An AI-visibility baseline measured with Periscope before launch, so there's a real before-and-after rather than a claim
• Performance optimised, because Google measurably rewards fast pages

That baseline comes with a commitment attached: your AI visibility gets re-measured at 90 days and reported honestly, and if it hasn't moved I keep working the priority pages at no extra project fee until the next measure.

The ongoing work — content cadence, ranking improvements, the AI-visibility loop — sits in the retainer if you want that level of support. But the foundation is part of the build, regardless of what happens after.

6. Performance benchmarks

Every site I ship is built to clear these targets on launch day, measured on mobile with realistic 4G throttling:

• Lighthouse Performance: 95+ (most builds land in the high 90s)
• First Contentful Paint: under 1.0s
• Largest Contentful Paint: under 1.5s
• Cumulative Layout Shift: under 0.05
• Time to Interactive: under 2.0s

The things that get traded off to hit those targets: heavy JavaScript frameworks where they aren't needed, third-party chat widgets that auto-load on every page, embedded video players that initialise before the user asks for them, hero carousels, decorative animation libraries. In most cases these add to the page weight without adding to the conversion rate.

The things that don't get traded off: design quality, real photography, custom typography, considered interaction. Good design and a strong Lighthouse score aren't in tension — most slow sites are slow because of add-ons that crept in, not because the design itself is ambitious.

7. Post-launch reporting

Every project includes a 6-month post-launch reporting cycle. The monthly report covers:

• Search Console performance — queries, clicks, impressions, position changes
• Google Analytics 4 — sessions, top pages, enquiry events
• AI visibility — how often ChatGPT, Gemini and Perplexity name you on the buyer questions that matter, tracked in Periscope against the pre-launch baseline
• Core Web Vitals from real users (Chrome UX Report data)
• Ranking position for the priority terms agreed in discovery
• Which capability pages are actually pulling enquiries, and which aren't earning their place
• One specific recommendation for the coming month — content, technical, or campaign

At the 3-month mark we have a working call to check whether the assumptions in the discovery brief are holding up against what's actually happening. At the 6-month mark we review whether an ongoing retainer makes sense. For some businesses it clearly does; for others the launched site does its job without further investment. The right answer is the one that fits your situation — not the one that's most lucrative on my side.

8. Patterns I'd usually steer you away from

A handful of decisions come up on most projects, and these are the ones I'll typically push back on if asked to include them. None of these are absolute rules — context matters — but the default position is to leave them out, because the cost they impose usually outweighs the benefit on a technical B2B site.

• Chatbots in the hero. They can work in some categories, but an engineer trying to find your tolerance range doesn't want a chat bubble in the way — and on a founder-led business they undercut the direct-access positioning the rest of the site is making.
• Email-capture popups on first visit. The conversion lift rarely justifies the friction, particularly on mobile. Worth trying later if there's a specific reason — not as a default.
• Image carousels in the hero. Engagement data on carousels is consistently weak; users tend to ignore content that moves, and the performance cost is real.
• Stock photography standing in for your own work. The most common unforced error in manufacturing. A generic shot of a gleaming robot arm from a photo library says nothing; a real photograph of your shop floor, your machines and the parts you've actually made is one of the strongest credibility signals you have. If the photography doesn't exist yet, getting it is part of the project.
• "As featured in" logo strips without genuine placements behind them. When the placements are real, this is one of the strongest trust signals available. When they aren't, it reads as fake and undermines everything else on the page.
• Counter widgets with inflated numbers. If the real number is impressive, show it. If it isn't yet, don't fabricate.
• Certifications and standards claimed loosely. If you're ISO 9001 or AS9100, say so precisely, with scope and certificate detail. Vague quality claims are worth less than nothing to a buyer whose job depends on getting the supplier choice right.
• Animation that exists for its own sake. Subtle micro-interactions, fade-up reveals, considered page transitions — yes. Bouncing arrows, parallax everywhere, motion that competes with content for attention — usually no.

If your business genuinely benefits from one of these, we'll talk through it in discovery. The list above isn't a wall — it's the starting position.

9. A clear read on pricing

Pricing is published on the services page. The short version: website builds start at A$8,000 with most rebuilds landing between A$8k and A$20k, trade portals and ERP-integrated projects are quoted to scope and typically run A$25k–A$130k+, and care & growth retainers start at A$300 per month — month-to-month, no lock-in.

The reason the entry price sits where it does: this is genuinely a one-person operation, and the hours that go into a project — discovery, capability content, design, build, the Google and AI visibility foundation, reporting — don't compress below a certain level without quality starting to drop. A manufacturer site is also simply more work than a five-page brochure: the whole point is depth across every process and material you want to be found for. The pricing reflects what's actually involved, not what the market expects.

What you won't find is a calculator that spits out a number. A range that runs from A$8k to well past A$100k depends entirely on scope — how many capabilities need pages, whether there's a portal, whether your ERP is in the picture — and pretending a form can settle that would be a guess dressed up as a quote. Bands in the open, then a firm number once I understand the job.

If your budget is below that range, there are template-based options that deliver a working site at lower price points, and I'd genuinely point you towards one if that's the right fit. If the project needs six months and a five-person team, I'd want to use discovery to be honest about whether a larger agency would serve you better — there's a point above which scale matters more than what a solo operator can deliver, and over-promising on that helps nobody.

If this lines up with how you'd want a project to run, the 15-minute discovery call is the next step. If parts of it don't quite map to your situation, the call is still useful — we can talk through whether a tweak to the approach makes sense for your project, or whether you'd be better served by a different kind of setup.