WEBSITE DESIGN FOR MEDICAL DEVICES AND REGULATED INDUSTRIES

What sets a medical device website apart from other company websites is that you cannot write freely about the product. Claims about the product must match the intended purpose and the scope of the CE marking, and the EU Medical Device Regulation, MDR (EU 2017/745), prohibits wording that could mislead about what the product is intended for, how safe it is and how it performs (Article 7). That changes how the website is built, not just how it is written.

Three things need to be in place before design and build start. A register of approved wording: which claims have been reviewed, for which product and for which market. An approval workflow: who writes, who does the regulatory review and who can publish. And a version history, so that you can show which text was live on a given date.

We recommend building the workflow into the CMS rather than handling it by email. Approved wording sits in dedicated fields that are reused wherever the product is mentioned, and locked for anyone who only updates news and careers pages. All changes are previewed on staging, where your regulatory lead reviews them before publication. How strict the workflow should be is set by your quality procedures – we build to them, not the other way round.

Yes. We work with your register of approved wording as the source and never change what is claimed about the product. What we work on is everything around it: structure, headings, order, context and the texts that are not product claims, such as the company description, research overview and careers pages. Product claims are entered word for word and marked in the CMS so that they are not accidentally rewritten. The register, your tone of voice and what must not be said are also collected in a context file for AI, so every new draft – ours or yours – starts from the approved wording. All copy goes through your approval workflow before publication.

The workflow is built into the CMS. We separate fields that can be changed freely from fields that carry product claims, give different roles different permissions and preview all changes on a staging URL, where your regulatory lead reviews them before publication. If you need formal workflows with a traceable history per field, we build that in a headless CMS. How strict the workflow should be depends on your quality procedures – we adapt the build to them.

In medtech, search engine optimisation is about accuracy first and visibility second. If a clinician asks ChatGPT whether your product is approved for a particular indication, and the information cannot be read on your website, the answer is rarely "I don't know". It is a no – or a guess that promises more than the CE marking covers. The first costs you the deal; the second, your credibility.

We optimise structure, headings, information architecture and technology – never the claims. Intended purpose, indications, contraindications and regulatory status are written as self-contained, quotable passages under headings phrased as questions, with the same wording as in the approved register. Schema markup, available as an add-on, describes the product, the organisation and the publications, and the company is described consistently on the website and in external profiles, so that you come across as a clear entity. Our general approach is described under AI visibility and AEO.

Our partnership with Suturion has run since 2024: the website was moved from WordPress to Webflow, and content, structure and SEO have been developed continuously since, so that the business, the products and the research are described consistently. See how we built Suturion's website.

Instructions for use, safety notices, declarations of conformity, certificates and technical documentation must be easy to find and linked to the right product and the right version. We recommend modelling the documents as a separate collection in the CMS, not as loose PDF files in a media library: each document gets fields for type, product, language, version, validity and which document it replaces. The product page pulls in its documents automatically, the library can be filtered by product and language, and earlier versions are visibly archived.

If you provide electronic instructions for use (eIFU) under Regulation (EU) 2021/2226, the rules include requirements for how the instructions are made accessible on the website and for earlier versions to remain available. The same structure supports this: every set of instructions is a separate entry with a version and a date. If your products have a unique device identification (UDI), the identifier can be stored as a field on the product.

Each document also gets its own HTML page with a title, summary and metadata, with the PDF file linked from there. A PDF without a page around it lacks context and structured data, is often poorly indexed and risks being described incorrectly by AI assistants.

• Scientific authority without losing readability. Google treats health-related content as YMYL and, according to Google Search Central, holds it to a higher standard of E-E-A-T – the same signals determine whether AI assistants cite you. We recommend a publications collection in the CMS, author profiles for founders, researchers and medical advisers, and a clear dividing line between what the research shows and what the product is intended for. Readability comes down to order: the answer first, then the mechanism, then the references. For Cymbathera, founded by two internationally cited researchers in inflammation and vagus nerve stimulation, that was exactly the balance the website had to strike.
• Three audiences on the same website. Clinicians want to know the indication, evidence and use; procurement officers want certificates and regulatory status; investors look for milestones, publications and the team. Each audience gets its own entry point – but the product description is drawn from the same fields everywhere, so an investor page never describes the product more favourably than the product page does. There is more on structuring a website for a buying committee on the page about our B2B web design agency.
• Several markets, regulatory status per market. The product's status can differ between markets: CE marked in the EU but not yet approved in the US, or approved for different indications. What can be said therefore differs by market, not just by language. We keep language and market separate in the CMS model – language governs translation, market governs which products, claims and documents are shown – and set hreflang, URL structure and instructions for use per language before the build, so a new market becomes an editorial task, not a new web project.

Both tracks work for medical technology companies; the choice depends on the volume of documents, the approval workflow and system integrations. We recommend Webflow when the marketing department will do its own publishing, the volume of documents is manageable and approval can be handled with roles, locked fields and preview on staging – that is how both Suturion and Cymbathera are built. We recommend a coded website with a headless CMS when the document library is large and version-controlled, when the workflow requires a traceable history per field or when the website needs to pull data from your own systems. On that track, structural changes require code; if you have no developer of your own, a maintenance agreement is often a good idea, and if you do, they can take over completely. On the first call, we compare the two tracks on total cost in year one and year three.

It depends on the number of collections rather than the number of pages: products, documents, publications and profiles are separate page types that have to be modelled and built. Multiple markets, a formal approval workflow and integrations with your own systems add to the cost. If you already have a finished design and a complete register of approved wording, the project is smaller. We give you a fixed price after a free call, and there is a calculator in our guide to what a website costs.

Yes, if the structure is planned for it from the start. We keep language and market separate in the CMS model: language governs translation, market governs which products, claims and documents are shown. That way, the product's regulatory status can differ between markets without you needing parallel websites. We set hreflang and URL structure per language from the start, so a new market becomes an editorial task rather than a new build.