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 produkten på samma sätt som kunderna måste? Ingen särskild intern version, ingen genväg via ett internt API. Samma nedladdning, samma instruktioner, samma dashboard.

Vår marknadsföringssajt, den du läser det här på, är en Next.js App Router-applikation: landningssidor, produktsidor, dokumentation och den här bloggen, drygt hundra sidor på två språk. En tidigare version av inlägget beskrev en integration som vi sedan dess har ersatt. Den här versionen beskriver vad sajten kör i dag, hur vi installerade det och vad vi lärde oss av att göra det ordentligt.

Obs: Dynamic SEO är i tidig åtkomst. Skriv upp dig på väntelistan för att vara bland de första som testar.

Regeln: installera som en kund

Dogfooding betyder bara något om man går kundens väg. Så vi satte en regel: dynamicseo.com får Dynamic SEO genom Next.js-guiden på sidan Integrera, steg för steg, utan något som en kund inte har.

Det uteslöt några bekvämligheter. Paketet finns inte på npm, så vi laddar ner samma tarball från appen, committar den i repot och installerar från den sökvägen. Att uppgradera betyder att ladda ner den igen, precis som en kund skulle göra.

Implementationen

Hela integrationen är en wrapper i next.config och tre miljövariabler.

npm install ./vendor/dynamic-seo-nextjs.tgz

// next.config.js
const { withDynamicSEO } = require('@dynamic-seo/middleware/nextjs/config')

const withDseo = withDynamicSEO({
  apiUrlEnv: 'DYNAMIC_SEO_WORKER_URL',
  domainEnv: 'DYNAMIC_SEO_DOMAIN',
  siteKeyEnv: 'DYNAMIC_SEO_SITE_KEY',
  include: [/\(marketing\)[\\/]/],
})

module.exports = withDseo(withNextIntl(nextConfig))

Två detaljer spelar roll för en sajt som vår:

Ytterst. Vi omsluter redan next.config med next-intl, så Dynamic SEO ligger runt allt annat.
include. Samma Next.js-app serverar också den inloggade dashboarden under app/. Mönstret i include begränsar wrappern till route-gruppen (marketing), så att bara publika sidor berörs.

Ingen middleware ändras och inga layouter ändras. Vid bygget omsluter wrappern varje sidas egen generateMetadata och lägger det vi publicerar ovanpå. En sida utan något publicerat behåller sin egen metadata. Det är den reserven som gör installationen säker, och, visade det sig, också den som kan dölja en trasig installation.

Vad vi hittade när vi gjorde det ordentligt

En nyckel som nekats i månader

När vi flyttade sajten till kundens väg tittade vi på vad den faktiskt hade gjort. Sajten hade anropat vår kant hela tiden, runt tusen gånger om dygnet, och nästan varje anrop hade nekats. Nyckeln i deployen var inte sajtens aktuella nyckel.

Ingen märkte något, eftersom ingenting såg trasigt ut. Ett nekat anrop faller tillbaka på sidans egen metadata, så varje sida renderades som vanligt. Integrationen var installerad, körde och levererade ingenting.

Värre: vårt eget verifieringssteg hade sagt att anslutningen fungerade. Det testade nyckeln som låg i appen, inte nyckeln som sajten skickade, så det kunde aldrig upptäcka fel nyckel i en installation.

Miljövariabler som läses tillbaka tomma

Vår värd sparar miljövariabler för produktion som känsliga, vilket betyder att de läses tomma i efterhand. Ett tomt värde ser exakt ut som ett saknat, så man kan inte läsa den deployade nyckeln för att jämföra. En ändring av variabeln i värdens dashboard behöll dessutom det gamla värdet; att ta bort den och lägga till den igen fungerade. Och en ändrad variabel gäller först efter en ny deploy.

Inget av det här är exotiskt. Det är vad en kund också råkar ut för, och därför står det nu i guiden och i hjälppanelen i stället för i våra huvuden.

Den första leveransen

Med rätt nyckel och en ny deploy publicerade vi en sida, ett blogginlägg vars publicerade titel och beskrivning är desamma som sidans egna. Ungefär en och en kvarts minut senare bar den levande sidan <meta name="dynamic-seo" content="active">, taggen som skrivs på varje levererat svar. Dokumentationen lovar inom fem minuter.

Vad vi ändrade i produkten

Allt det här började som något vi gjorde fel på vår egen sajt:

Verifieringssteget läser vad sajten faktiskt gör. I stället för att testa nyckeln som ligger i appen visar det sajtens egna anrop: om nyckeln godkänns, om något är publicerat och om något har levererats, med en länk direkt till publicering när installationen fungerar men inget är ute än.
En nekad nyckel visar sig själv. När anrop nekas visar appen början på nyckeln som skickas bredvid början på nyckeln den väntar sig. Ett fel som var tyst i månader syns nu med en blick.
Varningen försvinner när nyckeln är rättad. Nekningar räknas bara efter det senaste godkända anropet, så en rättad installation slutar få höra att den är trasig.
Ägaren får veta. Om en sajts anrop har nekats i ungefär ett dygn och inget har godkänts får sajtens ägare ett mejl.
Att regenerera en nyckel frågar först, överallt. En ny nyckel stänger ute varje installation som fortfarande skickar den gamla. En inställningssida gjorde det med ett klick. Nu frågar alla.
Guiden blev kortare och hjälpen längre. Stegen säger vad man ska göra. Resonemanget, inklusive värdens egenheter ovan, flyttade till hjälppanelen, ett klick från varje steg.

Råd till team som installerar Dynamic SEO

Avgränsa från dag ett. Delar din publika sajt och din app samma Next.js-projekt, använd include så att bara de publika sidorna omsluts.

Behåll din egen metadata. Integrationen lägger publicerade värden ovanpå din generateMetadata. Allt du inte har publicerat behåller ditt värde, så installationen kan inte göra en sida sämre.

Gör en ny deploy efter varje ändrad variabel, och bedöm inte en variabel genom att läsa tillbaka den om din värd markerar den som känslig. Bedöm installationen efter dess anrop i stället.

Verifiera från sajtens sida. Leveranskortet och verifieringssteget visar din egen sajts anrop. Titta på dem efter första deployen, inte bara på testknappen. En tyst reserv är fortfarande en reserv.

Avslutande tankar

Det mest användbara dogfoodingen gjorde för oss var inte att bevisa att integrationen fungerar. Den visade hur en integration kan fallera utan att någon ser det, och att vår egen produkt hade rapporterat det felet som framgång.

Den säkra reserven är fortfarande rätt design: en saknad eller felaktig nyckel ska aldrig ta ner en kunds metadata. Men ett säkert fel behöver vara ett synligt fel. Det är den ändringen övningen gav, och varje kund får samma.