UnitGlide

Omrekenen is een van de meest voorspelbare zoekintenties die er bestaan. Iemand typt een eenheid, een tweede eenheid en soms een getal, en verwacht binnen een seconde antwoord. De vraag is groot, loopt het hele jaar door en verandert nauwelijks van vorm. Precies daarom is de niche ook volgebouwd, en precies daarom is de kwaliteit er zo wisselend: als het verkeer toch wel komt, is er weinig reden om er nog moeite in te steken.

Wat je in de praktijk aantreft, is een tabel zonder herkomst, een pagina die aan alle kanten is dichtgezet met advertentieruimte, en een invoerveld dat pas reageert als het scriptwerk klaar is. Voor de bezoeker betekent dat wachten op een antwoord dat neerkomt op twee rekenstappen. Voor ons was dat het aanknopingspunt: de inhoud is triviaal en voor iedereen gelijk, dus het onderscheid kan alleen uit uitvoering komen. Snelheid, rust, en zichtbaar maken waar een getal vandaan komt.

We kozen bewust voor breedte in het model en discipline in de uitwerking. Twaalf categorieen, van lengte en massa tot druk, energie, digitale opslag en typografie, elk met een eigen basiseenheid. Typografie zit erbij omdat px, rem en pt dagelijkse conversies zijn voor ontwerpers en developers, een groep die op de gangbare omrekensites eigenlijk nergens terechtkan. Het is meteen ook de categorie waar we het eerlijkst moesten zijn: rem rekenen we tegen een root van 16px, de gebruikelijke standaard, en dat staat er met zoveel woorden bij, inclusief de instructie om je uitkomst te schalen als je project een andere root gebruikt.

UnitGlide heeft een eigen design-systeem: een enkel CSS-bestand met eigen custom properties, en verder niets. Geen Tailwind, geen componentbibliotheek, geen thema dat we ergens vandaan hebben gehaald. Dat is een keuze met consequenties in twee richtingen. We schrijven elk onderdeel zelf, wat trager is en waar we zelf de onderhoudslast van dragen. Daar staat tegenover dat we geen framework-gewicht meesturen en dat er niets tussen zit tussen wat we willen tonen en wat de browser krijgt: elke regel die er staat, staat er omdat wij hem hebben gezet.

De visuele richting is die van meetgereedschap. Een lichte grafietgrijze basis, wit oppervlak, een enkele staalblauwe accentkleur, en verder rust. Het liniaalmotief, een fijne repeterende streepjeslijn, is de meest letterlijke verwijzing en scheidt op de homepage de converter van de categorielijst eronder. Het signaal dat consequenter terugkomt is subtieler: getallen staan in een monospace met tabellarische cijfers, in de invoervelden, in de uitkomst en in de referentietabellen. Kolommen lijnen daardoor uit en een cijfer verspringt niet terwijl je typt, wat precies de onrust wegneemt die je op een converter het minst kunt gebruiken.

De hierarchie op de tool-pagina's is bewust plat. Het invoerveld staat bovenaan en werkt meteen; daaronder komen pas de formule, de tabel en de veelgestelde vragen. Advertentieruimte bestaat wel als component, maar rendert niets tenzij die via een omgevingsvariabele wordt aangezet, en reserveert dan vooraf een vaste hoogte zodat de layout niet verspringt zodra er iets in valt. Achter diezelfde schakelaar zit de consent-banner, want die is er alleen nodig als er advertenties zijn. De standaardtoestand van de site is daarmee: geen advertentie, geen cookiedialoog, geen ruis. Dat is niet iets wat we later hebben aangezet, het is hoe de site nu draait.

UnitGlide draait op Next.js 16 met de App Router en React 19, in TypeScript met strict mode aan. De afhankelijkhedenlijst is drie pakketten lang: next, react en react-dom. De twee dynamische routes zetten dynamicParams op false en genereren hun parameterlijst vooraf, zodat de build de pagina's oplevert die in de datasets staan en een verzonnen URL daarbuiten een 404 krijgt in plaats van een gerenderde pagina. Servercode van onszelf is er niet: er staat geen route handler in de app-boom, en er zit geen database- of API-client in de afhankelijkheden.

Het rekenhart is opzettelijk klein. Elke categorie kent een basiseenheid; elke eenheid draagt een factor die zegt hoeveel basiseenheden er in een gaan. Omrekenen is dan waarde maal factor van, gedeeld door factor naar. Temperatuur past niet in dat model omdat elke schaal een ander nulpunt heeft, dus die drie eenheden dragen expliciete formules naar en vanuit Kelvin. Voor de client wordt datzelfde model geserialiseerd: de factoren gaan een op een mee, zodat het getal in de vooraf gerenderde tabel en het getal dat verschijnt terwijl je typt op dezelfde waarde teruggaan. De temperatuurformules zijn de uitzondering, want functies kunnen de server-client-grens niet over. Die staan daardoor twee keer, in de bibliotheek en in de converter-component, en dat is de zwakste plek in het model: er is geen mechanisme dat de twee aan elkaar bindt, dus bij een wijziging moeten beide plekken met de hand mee.

Voor de bezoeker vertaalt dat zich in twee concrete dingen. Snelheid: de pagina is voorgerenderde HTML met een klein stukje interactieve JavaScript eromheen, dus het antwoord voor de standaardwaarden staat er al voordat er iets is uitgevoerd. En privacy: het omrekenen gebeurt in het tabblad, wat je in een converter intypt gaat nergens heen. Dat komt niet doordat we het beloven, maar doordat er in deze repo geen kant is waar het heen zou kunnen. Die formulering staat ook in de footer, en dat kan omdat het over het omrekenen gaat en niet over de hele site: het contactformulier stuurt wel degelijk iets naar een server, en dat benoemen we apart.

Een converter die er goed uitziet maar ergens een cijfer verkeerd heeft, is waardeloos. De factoren in het datamodel zijn daarom de exacte, gedefinieerde waarden: de pound als 0,45359237 kilogram, de ounce als 0,028349523125 kilogram, de inch als 0,0254 meter, de mijl als 1609,344 meter, de acre als 4046,8564224 vierkante meter. Geen afrondingen die er goed genoeg uitzien. Waar een keuze bestaat, zetten we die in de tekst op de pagina zelf: de site gebruikt US-vloeistofmaten voor cup, pint en gallon, en decimale (SI) eenheden voor digitale opslag waarbij een kilobyte 1000 bytes is. Dat zijn de plekken waar bezoekers anders een verschil zien en niet weten of het aan hen ligt.

Op de tien conversieparen met de meeste vraag gaan we een stap verder. Die pagina's tonen een echte afleiding van de factor, stap voor stap, plus een blok met de bekende verwarringen die mensen bij dat specifieke paar op het verkeerde been zetten. Bij pounds en ounces is dat de troy ounce, die bijna tien procent zwaarder is en waar bovendien twaalf in een troy pound gaan in plaats van zestien, en de fluid ounce, die volume meet en geen massa. Daaronder staat een bronvermelding met een doorklikbare link. Die bronnen zijn BIPM (de SI-brochure), NIST (Handbook 44, Special Publication 811, de pagina over binaire prefixen en die over de survey foot) en voor de cup van 240 ml de FDA-regelgeving in 21 CFR 101.9.

Alle getallen in de tabellen worden berekend: de referentierijen, de dichte decimale ladders, de omgekeerde richting, allemaal door dezelfde convert-functie uit hetzelfde datamodel. Ook de voet-en-inch-pagina's, die niet in het gewone paarmodel passen, rekenen door op de echte factoren van foot en inch in plaats van op een eigen constante. Een correctie op een factor werkt daarmee in de tabellen overal tegelijk door. De afleidingen en de FAQ-antwoorden op die tien focusparen zijn wel met de hand geschreven, met de getallen erin uitgeschreven, want een uitleg die zichzelf genereert leest als een uitleg die zichzelf genereert. Dat is de bewuste ruil: iets meer zorg bij een wijziging, in ruil voor de enige tekst op de site die daadwerkelijk iets uitlegt.

De 352 conversieparen ontstaan niet uit een volledige matrix van iedere eenheid tegen iedere andere, wat duizenden dunne pagina's zou opleveren. Ze komen uit twee lijsten: een handmatig samengestelde set van 63 paren met aantoonbare zoekvraag, en een sweep waarin per categorie een paar hub-eenheden aan de rest van hun categorie worden gekoppeld. Beide richtingen worden aangemaakt, duplicaten eruit gefilterd, en paren over categoriegrenzen heen geweigerd, zodat er geen pagina kan ontstaan die kilogrammen naar seconden omrekent. Het resultaat is een aantal dat past bij wat we kunnen onderbouwen.

Onder die paarpagina's heeft een tijdlang een extra laag gezeten: waardespecifieke pagina's op /convert/{paar}/{waarde}, elk gebouwd op een decimaal die in Search Console daadwerkelijk was ingetypt. In juli 2026 hebben we die laag weer weggehaald. De data liet weinig ruimte voor discussie: ze vingen over een venster van negentig dagen geen zoekvraag op, en nadat de paarpagina's zelf dichte decimale tabellen hadden gekregen, herhaalde het merendeel ervan alleen nog een rij uit de tabel van de eigen ouderpagina. Ze concurreerden dus met precies de pagina die we willen laten ranken.

Die URL's sturen nu met een 301 door naar hun ouderpagina, en de afweging staat in de code in plaats van dat hij is weggepoetst. De redirect legt uit waarom de laag is gesneuveld, inclusief het argument dat we er zelf ooit voor hadden, en het diepte-bestand opent met de regel dat dit geen pagina-farm is en dat het antwoord op decimale vraag een dichtere ladder op de bestaande pagina is en niet een nieuwe URL per waarde. Wat overblijft is systematisch. Titles en descriptions worden uit het datamodel gegenereerd en afgekapt op het laatste hele woord, zodat een SERP-snippet niet halverwege een woord breekt. De JSON-LD levert WebSite, BreadcrumbList en FAQPage, waarbij de FAQ-antwoorden dezelfde tekst zijn als op de pagina zelf. De sitemap bouwt zichzelf uit dezelfde datasets, met een vaste inhoudsdatum zodat lastModified niet bij elke deploy opnieuw stempelt. Er ligt een llms.txt voor taalmodellen, en een IndexNow-script dat we na een deploy draaien om de sitemap-URL's aan te melden.

UnitGlide begon op 3 juli 2026 en staat live op unitglide.net. Het is een van de 28 organische tool-sites die we volledig zelf hebben gebouwd en zelf onderhouden. Het domein is jong, dus we doen hier geen uitspraken over posities of verkeer; wat we wel kunnen laten zien is de staat van het werk: 373 statische pagina's die uit een gecontroleerd datamodel komen, waarin de getallen op de definities teruggaan en waarin een URL die niet in de datasets staat ook niet gebouwd wordt.

De site is bovendien niet af in de zin dat we hem hebben neergezet en zijn weggelopen. De diepte-inhoud op de focusparen is er gekomen nadat Search Console liet zien dat de zoekvraag die de site nu krijgt vooral uit decimale varianten bestaat, terwijl de generieke paarpagina het gezochte getal nergens noemde. Het intrekken van de waardepagina's kwam uit diezelfde bron, alleen dan als tegenbewijs voor iets wat we eerder zelf hadden gebouwd. Dat is de manier waarop we deze sites doorontwikkelen: kijken wat er echt binnenkomt, en de pagina's die daarop antwoorden concreet beter maken in plaats van er meer pagina's naast te zetten.

Voor wie overweegt met ons te werken, is dit misschien het nuttigste bewijsstuk dat we hebben. Niet een oplevering waarvan iemand anders de eisen schreef, maar iets waar we zelf verantwoordelijk zijn voor de strategie, het merk, de interface, de code en de vindbaarheid, en waar we ook zelf de gevolgen dragen van iedere afweging. De keuzes hier, geen framework, geen backend, geen pagina-farm, geen advertenties tenzij bewust aangezet, zijn de keuzes die we ook in opdrachtwerk zouden verdedigen. En als de data ons ongelijk geeft, halen we ons eigen werk weer weg.