Next.js in Eindhoven

Next.js development for Eindhoven technology and manufacturing

A Next.js development company working with Eindhoven technology and manufacturing firms. Technical documentation for several product versions at once, where the canonical URL decides what ranks.

Updated November 4, 2026

Working day overlap: About six hours, as in Amsterdam - two hours behind Ankara
Who buys here: High-technology manufacturers, semiconductor and equipment suppliers, engineering firms and the research-linked companies around them
What that changes: The documentation is the product's public surface, and several versions of it are supported at once
Local specifics: An engineer searching for an error message needs the page for their version, not the newest one, which is a canonical decision

Eindhoven's technology companies have a public surface that is mostly documentation, and documentation has an SEO problem that ordinary websites do not.

The buyers are high-technology manufacturers, semiconductor and equipment suppliers and the engineering firms around them. What their customers search for is an error code, a parameter name, a tolerance or an integration question - and what they need back is the page for the version they are running, not the newest one.

Four versions, one canonical

Supporting several product versions at once means several near-identical pages for every topic, and leaving them all to compete is the default and the mistake.

The pages differ in a paragraph and a code sample. To a search engine they look like four attempts at the same subject, so the signals split and it chooses - frequently the oldest version, because it has been linked to for longest and accumulated the most references. The result is engineers landing on documentation for software nobody runs any more.

The structure that works puts the version in the URL, declares the current version canonical and has the others declare it. Ranking concentrates where it should, the older pages remain reachable and indexable for the people who need them, and nobody has to guess. Canonicals and sitemaps is the mechanism.

Say which version this is, and make switching work

The second half of the same problem is on the page rather than in its metadata.

A documentation page has to state which version it describes, visibly, near the top. Anybody arriving from a search engine has no context otherwise, and the cost of reading the wrong version is a support ticket or a failed integration.

The version selector then has to preserve the page rather than returning to an index. Switching from version three to version four of the page you are reading should land on the same topic; if that topic does not exist in the other version, the honest response is to say so rather than silently sending somebody to a table of contents. That is a routing detail and it is the difference between a selector people use and one they stop trusting.

Documentation in the repository, marketing content outside it

These sites nearly always have two kinds of content with opposite requirements, and trying to manage both the same way is why they are painful.

Technical documentation changes when the product changes. It belongs in the repository as files, reviewed in the same pull request as the behaviour it describes, because that is the only arrangement in which the two stay in step. A documentation change that requires a separate system and a separate person is a documentation change that happens three weeks late or not at all.

Product and marketing pages are the reverse - they change for commercial reasons, by people who do not deploy, and they belong somewhere editable. So an Eindhoven site is usually two content sources on one domain: files for the documentation, a headless CMS for everything else.

Commercially

Scope fixed in writing before work starts, priced per project. The country-level ground - Dutch invoicing and e-invoicing, the accessibility statement, payment methods - is on the Netherlands market page.

Invoiced by Codefacture Yazılım A.Ş. in Türkiye, in euros by bank transfer, with no Turkish VAT because exported services are exempt.

Frequently asked questions

We support four product versions. How should the documentation be structured?

A version in the URL, one version declared canonical, and the others declaring it. The temptation is to let every version compete, which splits the signals across four near-identical pages and lets a search engine choose - usually the oldest, because it has been linked to for longest. Declaring the current version canonical concentrates the ranking there while the older pages remain reachable for the engineers who need them, which is the outcome you want in both directions.

Our customers keep landing on documentation for a version they do not use.

Which is the cost of not having made the canonical decision, and it has a second half - the page has to say which version it describes, prominently, with a way to switch. A version selector that preserves the current page rather than returning to an index is the difference between a useful switch and one nobody uses. The page should also be honest when a section does not exist in another version instead of silently redirecting to its index.

Should documentation live in the repository or in a CMS?

For technical documentation that changes with the product, in the repository as files, reviewed alongside the code that changed. That keeps a documentation update in the same pull request as the behaviour it describes, which is the only arrangement where the two stay in step. Marketing content is the opposite case and belongs somewhere editable without a deployment, which is why these two usually end up as two different systems on one site.

What makes documentation search actually work?

Scoping it to the version the reader is in, and indexing headings rather than only pages. An engineer searches for an error message or a parameter name, and the result has to land on the section rather than the top of a long page. Getting that right matters more than the choice of search tool, and it is mostly a question of how the content is structured when it is indexed.