Három kisebb, de valós téma, ami eddig kimaradt: hogyan tesztelsz végponttól végpontig a PR-preview URL-ek ellen, mire figyelj a többnyelvűségnél az edge-en, és mi változik a keresőoptimalizálásban, ha SSR-ből szolgálsz ki.
A 11. modulban a unit- és integrációs tesztelést néztük (Vitest a workerd-ben). Ami hiányzott: a böngészős, végponttól végpontig tartó teszt. Itt viszont a Cloudflare-modell egy komoly előnyt ad: a 8. modulból tudod, hogy minden PR kap egy éles, futó preview URL-t — vagyis nem kell tesztkörnyezetet feltámasztani a CI-ban, csak rá kell mutatni a tesztet.
.github/workflows/e2e.yml (vázlat)jobs:
e2e:
steps:
- uses: actions/checkout@v4
- run: npm ci && npx playwright install --with-deps chromium
# a preview URL-t a Workers Builds / wrangler kimenetéből vagy a PR-kommentből kapod
- run: npx playwright test
env:
BASE_URL: ${{ steps.preview.outputs.url }}import { test, expect } from "@playwright/test";
test("a felhasználó be tud lépni és látja a dashboardot", async ({ page }) => {
await page.goto("/login");
await page.getByLabel("Email").fill(process.env.TEST_USER!);
await page.getByLabel("Jelszó").fill(process.env.TEST_PASSWORD!);
await page.getByRole("button", { name: "Belépés" }).click();
await expect(page.getByRole("heading", { name: "Áttekintés" })).toBeVisible();
});A Nuxt i18n-modulja ugyanúgy működik a Workersen, mint bárhol — a különbségek a kiszolgálás oldalán vannak:
| Kérdés | Ajánlott megoldás | Miért |
|---|---|---|
| URL-séma | path-prefix: /hu/, /en/ | cache-barát (18. modul!), indexelhető, megosztható link |
| Nyelvfelismerés | először a felhasználó mentett beállítása, aztán Accept-Language, végül az ország (request.cf.country) | a cf objektum ingyen adja az országot — de az ország ≠ nyelv (CH, BE, CA) |
| Automatikus átirányítás | csak a gyökérről (/), egyszer, és megjegyezve | a minden oldalon újra-átirányítás rontja a SEO-t és bosszantja a felhasználót |
| Fordítási fájlok | a bundle része (statikusan importálva) | nincs futásidejű fájlrendszer (2. modul); a lusta betöltés a kliensoldalon működik |
| Dátum/szám/pénz | Intl API | a runtime beépítve hozza, nincs szükség nehéz könyvtárra (bundle-méret, 2. modul) |
Accept-Language alapján), és az oldal cache-elhető, akkor az első látogató nyelve ragad be mindenkinek (18. modul). Ezért a path-prefix a helyes minta. Ha mégis fejléc-alapú megkülönböztetés kell, akkor a nyelvnek a cache-kulcs részévé kell válnia — és ez ugyanaz a hibaosztály, mint a tenant-keveredés.A jó hír: SSR-rel a keresőoptimalizálás alaphelyzete jó — a robot kész HTML-t kap, nem üres <div id="app">-t. Amire figyelj:
useSeoMeta), ne kliensoldali JS-ből — különben a robot a generikus alapértelmezést látja.hreflang a nyelvi változatokhoz, és x-default a nyelvválasztó gyökérnek./app/*) tiltsd le a robotoknak — semmi értelme, hogy próbálja indexelni.Under Attack mód és az agresszív bot-védelem (22. modul) a keresőrobotokat is érintheti. A verifikált botokat a rendszer általában felismeri és átengedi, de ha saját, szigorú szabályt írsz (pl. „minden nem-magyar forgalom kap kihívást"), azzal kizárhatod a Googlebotot is. Ha SEO számít, a szabályaidnál mindig gondolj a robotokra — és ellenőrizd a Search Console-ban a lekérési hibákat.Mert minden PR kap egy éles, futó preview URL-t — nem kell tesztkörnyezetet feltámasztani a CI-ban. Buktatók: a preview-k közös staging erőforrásokon osztoznak (párhuzamos futások ütközhetnek → egyedi tesztadat és takarítás), és ha Access védi a preview-t, a CI-nak service token kell.
/hu/) az ajánlott i18n-séma?
Mert így a nyelv az URL része, tehát a cache-kulcs természetesen elválik (nem ragad be egy nyelv mindenkinek), a linkek megoszthatók, és a keresők külön indexelhetik a változatokat. Fejléc-alapú megkülönböztetésnél a nyelvnek a cache-kulcs részévé kell válnia.
A meta-adatokat (title, description, OG), a canonical URL-t, a hreflang-okat és a strukturált adatot (JSON-LD). Ha ezek kliensoldali JS-ből kerülnek be, a robot a generikus alapértelmezést látja.
A hivatalos teszt-kulcsokkal, amik mindig sikeres (vagy mindig sikertelen) eredményt adnak nem-produkciós környezetben. Ne a kódban kapcsold ki feltételesen a védelmet — az a beállítás egyszer élesben is ott maradhat.
Mert ugyanaz a tartalom több hoston is elérhető lehet (aldomain és az ügyfél custom domainje, 16. modul). A canonical mondja meg a keresőnek, melyik a hivatalos változat — enélkül duplikált tartalomként kezelheti.