Hur vi använder Dynamic SEO på vår egen marknadsföringssajt

Det finns ett enkelt test för alla utvecklarverktyg: använder teamet bakom det faktiskt sin egen produkt? Om svaret är nej, eller om det kommer med förbehåll, säger det något viktigt om produkten.

Vi byggde Dynamic SEO för att lösa problemet med att hantera SEO-metadata i stor skala utan att knyta varje ändring till en koddistribution. Vår marknadsföringssajt — den du förmodligen läser detta på — körs på Next.js App Router. Den har landningssidor, funktionsfördjupningar, integrationsguider och en växande blogg. Den behöver SEO-hantering. Så vi använder vår egen produkt för att tillhandahålla det.

Det här inlägget är en ärlig redogörelse för den implementationen. Vad vi konfigurerade, vad som fungerade direkt, vad som överraskade oss, och vad erfarenheten lärde oss om vår egen produkts design.

Observera: Dynamic SEO är för närvarande i tidig åtkomst. Funktionerna som beskrivs i detta inlägg återspeglar vår interna användning och kan utvecklas medan vi arbetar mot allmän tillgänglighet. Gå med i waitlisten för att vara bland de första att prova.

Varför dogfooding spelar roll

Termen "dogfooding" kommer från idén att äta sin egen hundmat — att använda produkten man säljer. Det är överanvänt inom tech, men den underliggande principen är sund. När du använder ditt eget verktyg dagligen stöter du på samma friktion som dina kunder. Du kan inte bortförklara ojämnheter när du själv drabbas av dem varje gång du uppdaterar en titel-tagg på ett blogginlägg.

För Dynamic SEO specifikt tjänar dogfooding tre syften:

1. Validering. Om vår integration inte fungerar smidigt på en standard Next.js App Router-sajt behöver vi veta det innan kunderna gör det.
2. Empati. Upplevelsen av installationen, arbetsflödena i dashboarden, tiden till första resultatet — vi upplever allt förstahand.
3. Trovärdighet. När vi säger till kunder att Dynamic SEO fungerar med Next.js kan vi peka på vår egen sajt som ett levande exempel.

Vi behandlar inte detta som en demomiljö. Vår marknadsföringssajt kör samma integrationspaket, samma middleware och samma dashboard som varje kund använder. Det finns ingen speciell intern version.

Vår sajt: vad vi arbetar med

Dynamic SEOs marknadsföringssajt är en Next.js App Router-applikation. Det är inte en trivial ensidessajt, men det är inte heller en enorm e-handelskatalog. Den befinner sig i det spann som många SaaS-marknadsföringssajter upptar: betydelsefull nog att behöva riktig SEO-hantering, liten nog att varje sida spelar roll.

I skrivande stund omfattar sajten ungefär 18 sidor:

• Startsida — den primära landningssidan med produktpositionering
• Produktöversikt — detaljerad förklaring av vad Dynamic SEO gör
• Funktionshub — sammanfattning av alla plattformsfunktioner
• 5 funktionsfördjupningar — individuella sidor för URL-hantering, meta-tagg-kontroll, strukturerad data, analys och integrationer
• Integrationssida — översikt över installationsvägar (WordPress-plugin, Node-middleware, REST API)
• Om oss och Kontaktsidor
• Blogg — en växande samling artiklar (du läser en just nu)

Var och en av dessa sidor behöver en unik titel-tagg, metabeskrivning, Open Graph-taggar för social delning, och i vissa fall strukturerad data. Blogginläggen behöver dessutom Article-typ strukturerad data och korrekta kanoniska URL:er för att undvika problem med duplicerat innehåll.

Innan Dynamic SEO hanterades allt detta genom generateMetadata-funktioner utspridda över kodbasen. Att uppdatera en enda metabeskrivning innebar att ändra en TypeScript-fil, öppna en pull request, vänta på CI och distribuera. Det fungerade, men det var precis den typ av arbetsflöde vi byggde Dynamic SEO för att eliminera.

Implementationen

Att konfigurera Dynamic SEO på vår egen sajt följde samma trestegsprocess som vi dokumenterar för kunder. Vi tog inga genvägar och använde inga interna API:er. Hela implementationen berör tre filer.

Att lägga till Dynamic SEO på vår Next.js-sajt krävde tre ändringar: installera paketet, lägga till en enda middleware-rad och placera en komponent i vår layout. Inga per-sidändringar behövdes.

Integrationen säkerställer att korrekt URL-kontext är tillgänglig för metadataupplösning. Layout-komponenten hanterar all metadatarendering för varje sida i marknadsföringssektionen — titeltaggar, metabeskrivningar, Open Graph-taggar och strukturerad data. Eftersom den körs som en Server Component inkluderas allt i det initiala HTML-svaret.

Vi konfigurerade integrationen att enbart appliceras på marknadsföringssidor, och hoppa över applikationsrutter och API-ändpunkter. Två miljövariabler i våra hosting-inställningar slutförde konfigurationen.

Det var hela implementationen. Inga per-sidändringar. Inga ändringar av befintliga generateMetadata-funktioner. Layouten hanterar allt.

Vad vi hanterar genom Dynamic SEO

Med integrationen på plats hanterar vi följande genom Dynamic SEO-dashboarden — samma dashboard som våra kunder använder:

Titel-taggar och metabeskrivningar

Varje marknadsföringssida har en titel och beskrivning som hanteras genom dashboarden. När vi kör ett A/B-test på positioneringsspråk uppdaterar vi titlar utan att röra koden. När vi inser att en metabeskrivning är för lång för mobila sökresultat trimmar vi den i dashboarden och ändringen är live inom en timme.

Open Graph- och Twitter Card-metadata

Metadata för social delning konfigureras per URL. Varje sida har en skräddarsydd OG-titel, beskrivning och bildreferens. Blogginlägg använder en mall som automatiskt genererar OG-metadata från inläggets titel och beskrivning, så nya artiklar får korrekta sociala kort utan manuell konfiguration.

Strukturerad data

Vi använder Dynamic SEO för att hantera två typer av strukturerad data:

• Organisation-markup på startsidan och om oss-sidan, som ger sökmotorer våra företagsuppgifter, logotyp och sociala profiler.
• Article-markup på varje blogginlägg, inklusive författare, publiceringsdatum och ändringsdatum. Detta hanteras genom en bloggmall — när vi publicerar en ny artikel genereras strukturerad data automatiskt baserat på mallreglerna.

Kanoniska URL:er

Varje sida har en explicit kanonisk URL inställd genom Dynamic SEO. Detta är särskilt viktigt för vår blogg, där inlägg är tillgängliga på både engelska och svenska. Den kanoniska URL:en plus hreflang-taggar säkerställer att sökmotorer förstår relationen mellan språkvarianterna.

Bloggmetadata i stor skala

Här visar mallsystemet sitt värde. Istället för att konfigurera SEO-metadata för varje blogginlägg individuellt definierade vi ett mallmönster för /blog/*-URL:er. Mallen drar in inläggets titel till meta-titeln (med vårt varumärkessuffix), använder inläggets beskrivning som metabeskrivning och genererar Article-strukturerad data med korrekta datum.

När vi publicerar ett nytt blogginlägg är dess SEO-metadata redo omedelbart. Inget dashboardbesök krävs för rutinmässiga inlägg — mallen hanterar det.

Vad vi lärde oss

Att använda Dynamic SEO på vår egen sajt under de senaste månaderna avslöjade flera saker om vår produkt som vi kanske inte hade upptäckt genom enbart kundfeedback.

1. Layout-only-approachen var rätt API-design

Tidiga prototyper av Next.js-integrationen krävde ett getDynamicSEO()-anrop i varje sidas generateMetadata-funktion. När vi försökte implementera det på vår egen sajt var friktionen omedelbart uppenbar. Vi hade 18 sidor. Var och en behövde en modifiering. Att lägga till en ny sida innebar att komma ihåg att inkludera anropet.

Layout-only-approachen — där DynamicSEOHead i marknadsföringslayouten hanterar alla sidor under den — föddes direkt ur denna erfarenhet. En ändring, fullständig täckning. Det är den typen av API-designinsikt som bara kommer från att vara sin egen kund.

2. Cache-timing spelar större roll än man tror

Vi konfigurerade caching för att balansera aktualitet med prestanda. Ändringar propagerar inom det konfigurerade cache-fönstret. Initialt satte vi ett aggressivt uppdateringsintervall, men i praktiken behöver vi nästan aldrig metadataändringar som propagerar omedelbart. Vad vi däremot behövde var att cachen förblev varm för prestanda.

Vi landade på ett längre cache-fönster som rätt balans. Metadataändringar tar som mest en timme att synas. I utbyte träffar den stora majoriteten av sidladdningar cachen och lägger till noll latens för SEO-metadatahämtningen. För en marknadsföringssajt där metadataändringar sker några gånger per vecka är detta rätt avvägning.

3. Sökvägsexkluderingar är inte valfria

Vi konfigurerade integrationen att enbart appliceras på marknadsföringssidor, och hoppa över applikationsrutter och API-ändpunkter. Utan denna konfiguration skulle integrationen försöka slå upp SEO-data för rutter som aldrig skulle ha metadata.

Det bröt inte något — integrationen hanterar saknad data graciöst — men det lade till onödigt arbete på varje förfrågan till den autentiserade delen av appen. Att konfigurera sökvägsexkluderingar eliminerade detta helt. Vi rekommenderar nu sökvägsexkluderingar som en obligatorisk del av installationen, inte en valfri optimering.

4. URL-validering fångade verkliga problem

Vår isSafeUrl-validering avvisade flera URL:er under den initiala konfigurationen. Några test-URL:er i vårt system hade protokoll-relativa sökvägar (//example.com/page) istället för absoluta URL:er. Andra hade efterföljande blanksteg som var osynliga i dashboarden men orsakade felmatchningar vid URL-upplösning.

Dessa var inte säkerhetsproblem — de var datakvalitetsproblem som skulle ha orsakat tysta metadatafelmatchningar. Valideringen upptäckte dem omedelbart, och vi fixade dem i dashboarden. Denna erfarenhet ledde till att vi lade till mer detaljerade valideringsfelmeddelanden i dashboard-gränssnittet för alla kunder.

5. Fallback-mönstret är essentiellt

Vi behöll medvetet de befintliga generateMetadata-funktionerna i våra sidfiler. När Dynamic SEO har metadata för en URL renderar DynamicSEOHead den och Next.js använder dessa taggar. När den inte har det (till exempel för en helt ny sida vi inte konfigurerat ännu) tillhandahåller sidans egen generateMetadata standardvärdena.

Detta fallback-mönster innebär att integrationen är rent additiv. Att installera Dynamic SEO kan inte göra din SEO sämre — i värsta fall ändrar den ingenting för sidor som inte är konfigurerade. Detta visade sig vara viktigt för vår egen tillit under utrullningen, och vi misstänker att det spelar ännu större roll för kunder som utvärderar produkten.

Resultat

Efter att ha kört Dynamic SEO på vår marknadsföringssajt i flera månader är de praktiska resultaten raka:

• 100% metadatatäckning över alla marknadsföringssidor, hanterat från dashboarden istället för kod.
• Noll-deploy-metadatauppdateringar. Titel-tagg-ändringar, beskrivningsjusteringar och ändringar av strukturerad data publiceras utan pull requests eller CI-pipelines.
• Malldriven blogg-SEO. Nya blogginlägg får komplett metadata automatiskt. Vi publicerar en artikel och dess SEO-konfiguration finns redan på plats.
• Validerad strukturerad data. Vår Organisation- och Article-markup klarar Googles Rich Results Test, och vi har sett Article-rika resultat i sökningen.
• Ingen prestandaförsämring. Med caching korrekt konfigurerad lägger metadatahämtningen till noll mätbar latens på sidladdningar.

Råd till team som implementerar Dynamic SEO

Baserat på vår egen erfarenhet, här är vad vi skulle säga till team som börjar med Dynamic SEO:

Börja med marknadsföringssajten

Om din applikation har både en publik marknadsföringssajt och en autentiserad app (som vår) börja med marknadsföringssajten. Den har sidorna som behöver SEO mest, metadatan ändras oftast, och teamet som hanterar den (marknadsföring) gynnas mest av att inte behöva teknik för varje uppdatering.

Konfigurera sökvägsexkluderingar från dag ett

Definiera vilka sökvägsprefix som ska exkluderas från Dynamic SEO-bearbetning innan du distribuerar. Som minimum, hoppa över dina autentiserade app-rutter, API-rutter och ramverkets interna sökvägar. Det här är inte för tidig optimering — det är korrekt konfiguration.

Matcha cache-timing med din faktiska kadens

Om du ändrar metadata en gång i veckan är ett cache-fönster på en timme generöst. Om du aktivt A/B-testar titlar dagligen kanske du vill ha 15 minuter. Välj inte det kortaste intervallet bara för att du kan. Caching är din vän.

Behåll generateMetadata som fallback

Ta inte bort din befintliga metadatakonfiguration när du installerar Dynamic SEO. Låt båda systemen samexistera. Dynamic SEO tar företräde när den har data för en URL, och din befintliga metadata fungerar som säkerhetsnät. Det gör utrullningen riskfri och återgång trivial.

Använd mallar för repetitiva mönster

Om du har en blogg, ett hjälpcenter eller någon sektion med många sidor som följer samma URL-mönster, konfigurera en mall istället för att konfigurera varje URL individuellt. Mallar är skillnaden mellan "det här skalar" och "det här skapar en ny uppgift för varje sida vi publicerar."

Avslutande tankar

Dogfooding är inte en marknadsföringsövning. Det är en kvalitetskontrollmekanism. Genom att använda Dynamic SEO på vår egen sajt hittade vi API-designproblem som ledde till bättre integrationsmönster, standardkonfigurationer som behövde justeras, och kantfall som vår testsvit inte hade täckt.

Produkten är bättre för att vi använder den. Vår marknadsföringssajts SEO är bättre för att vi hanterar den genom ett specialbyggt verktyg istället för utspridda generateMetadata-funktioner. Båda dessa resultat spelar roll, och båda krävde att vi var ärliga om vad som fungerade och vad som behövde ändras.

Dogfooding avslöjade tre saker vi inte förväntade oss: caching måste matcha din innehållsuppdateringsfrekvens, fallback-mönster är avgörande för resilient rendering, och sökvägsexkluderingsregler förhindrar att SEO-lagret stör applikationsrutter. Om du utvärderar en server-side SEO-plattform, testa dessa tre områden först.