SunAndMoon

Zonsopkomst, zonsondergang, gouden uur en maanfase zijn vragen die niet één keer beantwoord worden en dan klaar zijn. Ze verschillen per plaats, ze verschillen per dag, en bij dezelfde persoon komen ze met de seizoenen terug. Dat maakt het een aantrekkelijke niche, maar ook een niche waarin al decennia iets gevestigd staat. timeanddate.com heeft er een imperium gebouwd, sunrise-sunset.org vult een deel op, en daarachter ligt een lange staart van sites die vooral bestaan om advertenties te tonen.

Wat opvalt als je die pagina's zelf bezoekt, is hoe ver het antwoord af staat van de vraag. Je typt een stad en een datum in, en krijgt eerst een toestemmingsbanner, dan een advertentieblok, dan een dichte tabel waarin het getal dat je zocht ergens verstopt zit. De informatie klopt doorgaans wel, maar de weg ernaartoe is traag en rommelig. Dat is geen detail, want de bezoeker met deze vraag heeft haast: hij staat buiten, of hij plant een foto voor over een uur.

We hebben SunAndMoon daarom niet neergezet als een poging om breder te zijn dan de grote spelers. Op ruwe domeinautoriteit en dekking winnen we voorlopig niet, en dat hebben we ook zo opgeschreven in het masterplan. We richten ons op de dingen die wij wel in de hand hebben: het antwoord meteen in beeld, geen advertentiemuur, en de intenties die de gevestigde partijen minder goed bedienen, zoals schemering, dawn en dusk, blauw uur en gouden uur.

Het ontwerp begon bij een vraag die geen tabel kan beantwoorden: hoe voelt een almanak? We kwamen uit op een concept dat we LIVING SKY hebben genoemd, met één centrale regel: de site ís de lucht. De achtergrond van de pagina is een verloop dat meebeweegt met de stand van de zon op het moment van kijken. Wie 's nachts kijkt krijgt nachtblauw, wie bij dageraad kijkt krijgt dageraad. Er zijn vijf standen (night, dawn, golden, day, blue), elk met een eigen verloop en een eigen accentkleur, van maanzilver bij nacht tot amber in het gouden uur.

Technisch is dat één laag tokens in plaats van vijf thema's. Componenten lezen semantische rollen in plaats van vaste kleuren, en de vijf data-sky-blokken herdefiniëren die rollen. Een kleur verandert dus op één plek en werkt door in de hele interface. Een klein script in de head zet de juiste stand nog vóór de eerste paint op basis van het lokale uur, waarna de client die stand verfijnt naar de werkelijk berekende zonfase van de actieve stad. Er is ook een handmatige schakelaar, want soms wil iemand gewoon de nachtversie. Een eigen contrast-script rekent de kleurparen uit het tokensysteem na in de vijf standen en toetst ze aan WCAG-drempels, want een ontwerp dat met het licht meebeweegt kan in één stand stilletjes onleesbaar worden.

De rest van het systeem is bewust smal gehouden. Eén zelf-gehost lettertype (Outfit), geen CSS-framework, geen tweede accentkleur die met de lucht concurreert. De esthetische kern is het grote, dunne tabulaire cijfer: de tijd zelf is de vormgeving. De maan in beeld is geen emoji maar een SVG-schijf waarvan de fase daadwerkelijk berekend wordt; aan pictogrammen houden we het bij twee kleine tekstglyphs naast de labels voor sunrise en sunset. Het handtekeningelement is de horizonboog: een boog van zonsopkomst naar zonsondergang, met de zon op de plek die hoort bij hoe ver de dag op dat moment gevorderd is, berekend voor het echte nu in de tijdzone van de stad. 's Nachts rust de zon op de horizon en neemt de maan haar plaats in.

SunAndMoon heeft geen database, en de tools op de site halen tijdens gebruik niets bij een server op. De site is Next.js 16 met de App Router, React 19 en TypeScript in strict mode. De astronomische kern draait in de browser van de bezoeker: lib/astro.ts rekent met SunCalc de zonstanden, het blauwe en gouden uur, de schemeringsfasen, de maanfase en verlichting, de komende fases, de volle manen per jaar en de seizoenspunten uit. Wie een stad kiest en een datum verschuift, ziet het resultaat zonder dat er een verzoek de deur uit gaat.

Dat is geen technische puriteit om de puriteit. Het levert de bezoeker drie concrete dingen op. Snelheid, omdat er niets te wachten valt op een server die een tijd voor je uitrekent. Privacy, omdat de plaats en de datum die je in een tool opzoekt je apparaat niet verlaten, wat wij zichtbaar als merkbelofte voeren in plaats van als voetnoot. En robuustheid, want een pagina die al klaar is en zelf rekent, blijft werken. De site is bovendien installeerbaar als app, zodat hij opent op jouw lucht.

De afhankelijkheden zijn navenant klein: vier stuks bij runtime, namelijk Next, React, React DOM en SunCalc. Dat is geen sport, het is onderhoud: wat er niet in zit, kan later niet breken of verouderen. Aan de randen is er wel degelijk zorg besteed aan de moeilijke gevallen. Voor plaatsen boven de poolcirkel bestaat er geen zonsopkomst of zonsondergang in de gebruikelijke zin, dus detecteert de code die situatie apart en benoemt hem als middernachtzon of poolnacht in plaats van een leeg veld te tonen. Advertentie- en toestemmingsscaffolding bestaat wel in de code, maar staat uit achter een omgevingsvariabele, en die zetten we niet aan zonder expliciete beslissing.

De vindbaarheid is geen laagje bovenop de site, het is de structuur van de site. Uit de 246 steden groeit een boom die in de SEO-baseline op bijna vierduizend pagina-routes uitkomt. Per stad is er een zonpagina, en daaronder twaalf maandpagina's; dat zoncluster alleen al is goed voor ruim drieduizend routes. Daarnaast heeft iedere stad een maanfasepagina, een dawn-pagina en een dusk-pagina, elk cluster met een eigen ingang erboven. Bovenop die programmatische laag staan de concept-ingangen (daglengte, schemering, zonnemiddag, blauw uur), een gouden-uur-calculator en volle-maan-pagina's per jaar.

De pagina's in die boom bouwen hun metadata uit de stadsdata: een canonical, een eigen titel en beschrijving, en een JSON-LD @graph met Organization, FAQPage en BreadcrumbList. De FAQ's zijn geen vulling: ze worden per stad opgebouwd uit de werkelijke seizoensdata van die plaats, zodat de vraag over de langste dag in Reykjavík een ander antwoord krijgt dan diezelfde vraag in Singapore. OG-afbeeldingen worden gegenereerd met next/og, zowel voor de site als per stad, en er is een sitemap, een robots-route en een manifest.

Het lastigste punt in zo'n opzet is versheid. Een statische pagina die een concrete tijd voor vandaag in de HTML zet, is morgen aantoonbaar fout, en dat ziet Google ook. Onze oplossing heeft twee kanten. De indexeerbare tekst beantwoordt de vraag en de context en zit daarmee niet vast aan de tijden van één dag, terwijl de concrete tijden van vandaag als placeholder in de HTML staan en op de client worden ingevuld. Daarnaast wordt de paginalaag vooraf gebouwd en daarna via ISR ververst, stadspagina's elke zes uur en de jaarstabiele maandpagina's dagelijks, terwijl een dagelijkse cron om twee uur 's nachts de caches invalideert. Zo regenereert ook een stad die niemand bezoekt met de tijden van vandaag, zonder redeploy.

Dezelfde rekenkern die in de browser draait, staat ook als server-endpoint open voor anderen. Er is een gratis, publieke JSON-API die per stad de zon- en maandata teruggeeft: /api/sun/london, desgewenst met ?date=YYYY-MM-DD voor een andere dag. De respons bevat zonsopkomst en -ondergang, zonnemiddag, daglengte, het ochtend- en avondgouden uur, het blauwe uur, de drie schemeringsniveaus en de maanfase met verlichting, moonrise en moonset. Er is geen sleutel en geen registratie nodig, en omdat het endpoint alleen leest en geen geheimen kent, staat CORS bewust open.

Daarnaast staan er twee vormen waarin de data buiten de site verder leeft. Een insluitbare widget levert per stad een compacte LIVING SKY-kaart die een andere site via een iframe kan plaatsen; die is expres framing-vriendelijk, want het doel is juist dat hij ergens anders staat. Een abonneerbare kalenderfeed levert zonsopkomst en zonsondergang, en desgewenst het gouden uur, voor de komende negentig dagen, toe te voegen in een agenda-app. Omdat de feed een dagelijkse verversing adverteert, rolt dat venster van negentig dagen vanzelf mee.

Deze laag is geen bijproduct, hij staat als doel in het masterplan omschreven als de ontwikkelaarshaak en de backlink-motor, en heeft een eigen productpagina op /developers. De redenering is simpel: wij hebben de kern toch al, en iets waar anderen naar linken is voor een jong domein meer waard dan nog een pagina. Het is ook de reden dat juist deze drie routes per verzoek draaien, terwijl de productpagina die erover vertelt gewoon vooraf klaarstaat, net als de rest van wat geïndexeerd moet worden.

Bij bijna vierduizend pagina's kun je niet met het oog controleren of een wijziging iets gesloopt heeft. Daarom schreven we vier eigen controlescripts die bij elke wijziging groen moeten blijven. Een crawler leest de vooraf gebouwde HTML en legt het SEO-oppervlak vast als baseline: titels, meta's, canonicals, robots, de tekst en volgorde van de koppen, de interne linkdoelen en de vorm van de JSON-LD. Wie daarna iets verandert dat niet mag veranderen, krijgt dat direct terug als een verschil met de baseline in plaats van als een rankingdaling drie weken later. De andere drie poorten dekken de rest af: een contrastcheck over de vijf luchtstanden, een linkcheck op gebroken en verweesde interne links, en een check die verifieert dat de JSON-LD parseert en de vereiste types bevat.

Die discipline heeft een reden die verder gaat dan netheid. Een ranking-URL is een bezit, en de duurste fout in dit soort werk is een onbedoelde wijziging aan iets wat al gevonden wordt. Door dat vast te zetten in scripts in plaats van in goede voornemens, kunnen we snel doorbouwen zonder het opgebouwde te riskeren. Het loont vooral bij een redesign: die mag veranderen wat de bezoeker ziet, zolang hij niet verandert wat Google leest. Daarnaast houden we de regels expliciet vast in de repo zelf, in een brandbook, een masterplan en een statuslog, zodat een volgende sessie niet hoeft te raden wat het merk is of waarom iets zo staat.

SunAndMoon is jong. De eerste commit staat op 3 juli 2026, en de posities bouwen zich nog op, zoals bij elk nieuw domein. Wat er staat is de volledige fundering: 246 steden in 106 landen, bijna vierduizend vastgelegde pagina's, een eigen design-systeem, een rekenkern die op het apparaat draait, een open datalaag en een SEO-structuur die bewaakt wordt. De volgende stap ligt klaar in het plan, namelijk van een handmatig samengestelde stedenlijst naar een gegenereerde dataset met belangrijkheidsniveaus, uitgerold in golven waarbij we de volgende golf pas aanzetten als de vorige daadwerkelijk geïndexeerd is. Voor ons is deze site vooral een bewijsstuk: wij kozen de niche, bepaalden de positionering, tekenden het merk, schreven de rekenkern en bouwden de vindbaarheidsstructuur, van het kleurtoken tot de sitemap. Het laat zien welke keuzes wij maken als niets ons tot een compromis dwingt: geen advertenties, geen tracking, geen accountmuur, en een pagina die één vraag stelt en die meteen beantwoordt.