Dlaczego warto testować SEO automatycznie, skoro mam Search Console?

Bo Search Console informuje o problemie po fakcie — często z kilkudniowym opóźnieniem, gdy regresja jest już na produkcji i zdążyła zaszkodzić. Przypadkowy `noindex` albo zepsuty canonical potrafi wyciąć stronę z indeksu na tygodnie, zanim w ogóle zauważysz spadek ruchu. Test automatyczny w CI/CD wyłapuje taki błąd, zanim kod zostanie zmergowany — przesuwa wykrycie z „klient dzwoni, że ruch spadł" na „pull request nie przeszedł".

Playwright czy Cypress do testów SEO?

Oba narzędzia poradzą sobie z tym zadaniem, bo testy SEO sprowadzają się do sprawdzenia zawartości ` ` i zachowania przy przekierowaniach. W 2026 dla zestawów regresyjnych częściej rekomenduje się Playwright — ma wyższą stabilność testów, natywną integrację z GitHub Actions i wygodną obsługę wielu przeglądarek. Cypress świetnie sprawdza się przy szybkim testowaniu komponentów w trakcie developmentu. Jeśli zaczynasz od zera pod kątem regresji SEO w CI, postaw na Playwright.

Co konkretnie powinien sprawdzać test regresji SEO?

Minimum to: brak przypadkowego `noindex` na stronach, które mają się indeksować; poprawny i bezwzględny tag canonical; obecność tytułu i meta description; poprawność tagów hreflang na stronach wielojęzycznych; oraz to, czy kluczowe przekierowania zwracają status 301, a nie 302 czy łańcuch redirectów. Dla stron z danymi strukturalnymi warto dodać walidację obecności i poprawności JSON-LD.

Czy takie testy spowalniają pipeline CI/CD?

Minimalnie. Testy SEO są lekkie — sprawdzają zawartość HTML i nagłówki odpowiedzi, nie wymagają klikania przez całą aplikację. Zestaw kilkunastu asercji na kluczowych typach stron wykonuje się w kilkanaście sekund. To nieporównywalnie mniej niż koszt naprawy deindeksacji wykrytej dopiero na produkcji. Jeśli zależy Ci na czasie, możesz uruchamiać je równolegle z resztą testów albo tylko na zmienionych ścieżkach.

Jak testować redirecty 301 w Playwright?

Najpewniej przez wykonanie żądania bez automatycznego podążania za przekierowaniem i sprawdzenie statusu oraz nagłówka `Location` pierwszej odpowiedzi. W Playwright użyjesz do tego `request.get(url, { maxRedirects: 0 })` i zweryfikujesz, że status to 301, a `Location` wskazuje docelowy, kanoniczny adres. To wyłapie zarówno podmianę 301 na 302, jak i przypadkowe zerwanie przekierowania.

Automatyczne testy regresji SEO w GitHub Actions — noindex, canonical i redirecty pod kontrolą CI/CD

Artykuł w skrócie

Przypadkowy noindex to jeden z najdroższych błędów SEO — wycina stronę z indeksu i może długo pozostać niewidoczny.
CI/CD przesuwa wykrycie z produkcji na pull request — zamiast dowiadywać się po spadku ruchu, dowiadujesz się od czerwonego testu, jeszcze przed zmergowaniem zmiany.
Test SEO to sprawdzenie <head> i przekierowań — meta robots, canonical, tytuł, description, hreflang oraz status redirectów. Za pomocą lekkich asercji, a nie pełnych scenariuszy E2E.
Playwright to dziś rozsądny domyślny wybór — wyższa stabilność testów i natywna integracja z GitHub Actions; Cypress również się nadaje.
Redirecty testuj bez podążania za nimi — sprawdzaj status pierwszej odpowiedzi i nagłówek Location, żeby wyłapać podmianę 301 na 302 i zerwane przekierowania.
Koszt minimalny, a ochrona realna — kilkanaście asercji wykonuje się w sekundy, a chroni przed regresją, której naprawa liczona jest w tygodniach utraconego ruchu.

Dlaczego SEO też zasługuje na testy regresji

W praktyce testujemy logikę biznesową, komponenty, ścieżki użytkownika — a metadane SEO traktujemy często tak, jakby były odporne na zmiany. Tymczasem to właśnie one są wyjątkowo kruche, ponieważ zależą od konfiguracji, która może się łatwo wymknąć spod kontroli przy refaktorze. Przykładowo, ktoś zmienia komponent layoutu i niechcący usuwa tag canonical; ktoś inny dodaje noindex na środowisku staging i zapomina go zdjąć przed mergem do głównej gałęzi. Migracja routingu podmienia 301 na 302, przez co Google przestaje przekazywać moc linków. Scenariuszy jest mnóstwo i nieuwaga może drogo kosztować.

Wspólnym mianownikiem tych błędów jest to, że żaden z nich nie wywoła awarii widocznej dla użytkownika. Aplikacja działa sobie bez zarzutu, testy funkcjonalne są zielone, a problem ujawnia się dopiero, gdy ruch organiczny zaczyna spadać — czyli z perspektywy biznesu o wiele za późno. Test regresji SEO domyka tę lukę, bo sprawdza dokładnie te rzeczy, których nie widać gołym okiem, ale które decydują o tym, jak stronę traktuje wyszukiwarka.

Co dokładnie testować

Zanim napiszemy kod, warto ustalić zakres. Dobry zestaw testów SEO koncentruje się na kilku obszarach, które najczęściej ulegają regresji.

Pierwszy to — najważniejsza asercja w całym zestawie. Strony, które mają się indeksować, nie mogą zawierać noindex. Drugi to — musi istnieć, być bezwzględnym adresem i wskazywać właściwą wersję strony. Trzeci to podstawowe metadane, czyli tytuł i meta description, których brak albo pustka oznacza utratę kontroli nad tym, jak strona prezentuje się w wynikach.

Na stronach wielojęzycznych dochodzą tagi , których spójność łatwo zepsuć przy zmianach w i18n. Wreszcie przekierowania — kluczowe redirecty muszą zwracać 301, a nie 302 czy, co gorsza, prowadzić przez łańcuch pośrednich adresów. Każdy z tych obszarów to jedna albo dwie proste asercje, a razem tworzą siatkę, przez którą typowe regresje SEO po prostu nie przejdą.

Testy metadanych w Playwright

Zacznijmy od najważniejszego — sprawdzenia zawartości <head> na kluczowych typach stron. Poniższy test weryfikuje, że strona produktowa indeksuje się poprawnie i ma komplet metadanych.

Code

// tests/seo/metadata.spec.ts
import { test, expect } from '@playwright/test'
 
test.describe('Regresja SEO — metadane', () => {
  test('strona produktu ma poprawne metadane i nie jest noindex', async ({
    page,
  }) => {
    await page.goto('/produkty/przykladowy-produkt')
 
    // Najważniejsze: brak przypadkowego noindex
    const robots = await page
      .locator('meta[name="robots"]')
      .getAttribute('content')
    expect(robots ?? '').not.toContain('noindex')
 
    // Canonical istnieje, jest bezwzględny i wskazuje właściwy adres
    const canonical = await page
      .locator('link[rel="canonical"]')
      .getAttribute('href')
    expect(canonical).toMatch(/^https:\/\//)
    expect(canonical).toContain('/produkty/przykladowy-produkt')
 
    // Tytuł i description są obecne i niepuste
    await expect(page).toHaveTitle(/.+/)
    const description = await page
      .locator('meta[name="description"]')
      .getAttribute('content')
    expect(description?.length ?? 0).toBeGreaterThan(0)
  })
})

Logika jest prosta i czytelna, ale dokładnie ta prostota jest zaletą — każdy w zespole rozumie, co test sprawdza i dlaczego jego niepowodzenie blokuje merge. Asercja na noindex jest tu celowo postawiona jako pierwsza, bo to ona chroni przed najkosztowniejszym scenariuszem.

Testy przekierowań

Drugi filar to przekierowania. Tutaj kluczowy jest jeden szczegół: żeby sprawdzić status redirectu, nie wolno za nim automatycznie podążać, bo wtedy zobaczysz dopiero stronę docelową, a nie samo przekierowanie. W Playwright wykonujemy więc surowe żądanie z wyłączonym podążaniem za redirectami.

Code

// tests/seo/redirects.spec.ts
import { test, expect } from '@playwright/test'
 
test.describe('Regresja SEO — przekierowania', () => {
  test('stary adres przekierowuje 301 na nowy, bez łańcucha', async ({
    request,
  }) => {
    const response = await request.get('/stary-adres-produktu', {
      maxRedirects: 0,
    })
 
    // Status musi być 301 (trwałe), nie 302 (tymczasowe)
    expect(response.status()).toBe(301)
 
    // Location wskazuje docelowy, kanoniczny adres
    expect(response.headers()['location']).toBe('/nowy-adres-produktu')
  })
})

Ten test wyłapuje trzy typowe regresje naraz: podmianę trwałego 301 na tymczasowy 302 (przez co Google nie przenosi pozycji na nowy adres), zerwanie przekierowania, które zaczyna zwracać 404, oraz pojawienie się łańcucha pośrednich redirectów. Każdy z tych przypadków potrafi po cichu kosztować pozycje wypracowane latami, a tutaj kończy się czerwonym testem w pull requeście. Jeśli prowadzisz większą migrację adresów, warto połączyć to z wiedzą z artykułu o migracji treści i redirectach 301 przy przejściu z WordPressa na Next.js.

Wpięcie w GitHub Actions

Same testy nie chronią niczego, dopóki nie uruchamiają się automatycznie przy każdej zmianie. Centralną częścią automatyzacji jest , gdzie definiujemy workflow uruchamiany na każdy pull request.

Code

# .github/workflows/seo-regression.yml
name: Regresja SEO
 
on:
  pull_request:
    branches: [main]
 
jobs:
  seo-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
 
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
 
      - run: npm ci
      - run: npx playwright install --with-deps chromium
 
      # Build i start aplikacji w tle
      - run: npm run build
      - run: npm start &
      - run: npx wait-on http://localhost:3000
 
      # Tylko testy SEO — szybko i celowo
      - run: npx playwright test tests/seo

Po dodaniu tego workflow każdy pull request automatycznie buduje aplikację i uruchamia na niej zestaw testów SEO. Jeśli któryś nie przejdzie — bo ktoś zostawił noindex albo zepsuł canonical — GitHub oznaczy sprawdzenie jako nieudane i zablokuje merge. Aby ta blokada faktycznie działała, ustaw ten workflow jako wymagane sprawdzenie statusu w regułach ochrony gałęzi main. Dopiero wtedy zielony test staje się warunkiem wejścia kodu na produkcję, a nie tylko informacją, którą można zignorować.

Werdykt Labu

Regresja SEO to wyjątkowo podstępna i paskudna klasa błędów, bo nie wywołuje żadnej widocznej awarii — aplikacja normalnie działa, testy funkcjonalne są zielone, a strona po cichu wypada z Google. Przypadkowy noindex, zepsuty canonical czy podmieniony status przekierowania potrafią kosztować tygodnie ruchu, zanim ktokolwiek zauważy problem. Właśnie dlatego te rzeczy zasługują na taką samą ochronę testami jak logika biznesowa.

Mechanika jest bardzo prosta i tania we wdrożeniu: kilkanaście lekkich asercji w Playwright sprawdza zawartość <head> i zachowanie przekierowań, a GitHub Actions uruchamia je na każdym pull requeście i blokuje merge, gdy coś się nie zgadza. Koszt to sekundy w pipelinie, a w zamian zyskujemy bezpieczeństwo i święty spokój.

Jeśli chcesz wpiąć testy regresji SEO w pipeline swojego projektu Next.js, ale nie wiesz, od czego zacząć ani co dokładnie objąć asercjami, napisz do mnie — pomagam budować takie siatki bezpieczeństwa dopasowane do konkretnej architektury serwisu.

Artykuł w skrócie

Przypadkowy noindex to jeden z najdroższych błędów SEO — wycina stronę z indeksu i może długo pozostać niewidoczny.
CI/CD przesuwa wykrycie z produkcji na pull request — zamiast dowiadywać się po spadku ruchu, dowiadujesz się od czerwonego testu, jeszcze przed zmergowaniem zmiany.
Test SEO to sprawdzenie <head> i przekierowań — meta robots, canonical, tytuł, description, hreflang oraz status redirectów. Za pomocą lekkich asercji, a nie pełnych scenariuszy E2E.
Playwright to dziś rozsądny domyślny wybór — wyższa stabilność testów i natywna integracja z GitHub Actions; Cypress również się nadaje.
Redirecty testuj bez podążania za nimi — sprawdzaj status pierwszej odpowiedzi i nagłówek Location, żeby wyłapać podmianę 301 na 302 i zerwane przekierowania.
Koszt minimalny, a ochrona realna — kilkanaście asercji wykonuje się w sekundy, a chroni przed regresją, której naprawa liczona jest w tygodniach utraconego ruchu.

Dlaczego SEO też zasługuje na testy regresji

Co dokładnie testować

Zanim napiszemy kod, warto ustalić zakres. Dobry zestaw testów SEO koncentruje się na kilku obszarach, które najczęściej ulegają regresji.

Testy metadanych w Playwright

Zacznijmy od najważniejszego — sprawdzenia zawartości <head> na kluczowych typach stron. Poniższy test weryfikuje, że strona produktowa indeksuje się poprawnie i ma komplet metadanych.

Code

// tests/seo/metadata.spec.ts
import { test, expect } from '@playwright/test'
 
test.describe('Regresja SEO — metadane', () => {
  test('strona produktu ma poprawne metadane i nie jest noindex', async ({
    page,
  }) => {
    await page.goto('/produkty/przykladowy-produkt')
 
    // Najważniejsze: brak przypadkowego noindex
    const robots = await page
      .locator('meta[name="robots"]')
      .getAttribute('content')
    expect(robots ?? '').not.toContain('noindex')
 
    // Canonical istnieje, jest bezwzględny i wskazuje właściwy adres
    const canonical = await page
      .locator('link[rel="canonical"]')
      .getAttribute('href')
    expect(canonical).toMatch(/^https:\/\//)
    expect(canonical).toContain('/produkty/przykladowy-produkt')
 
    // Tytuł i description są obecne i niepuste
    await expect(page).toHaveTitle(/.+/)
    const description = await page
      .locator('meta[name="description"]')
      .getAttribute('content')
    expect(description?.length ?? 0).toBeGreaterThan(0)
  })
})

Testy przekierowań

Code

// tests/seo/redirects.spec.ts
import { test, expect } from '@playwright/test'
 
test.describe('Regresja SEO — przekierowania', () => {
  test('stary adres przekierowuje 301 na nowy, bez łańcucha', async ({
    request,
  }) => {
    const response = await request.get('/stary-adres-produktu', {
      maxRedirects: 0,
    })
 
    // Status musi być 301 (trwałe), nie 302 (tymczasowe)
    expect(response.status()).toBe(301)
 
    // Location wskazuje docelowy, kanoniczny adres
    expect(response.headers()['location']).toBe('/nowy-adres-produktu')
  })
})

Wpięcie w GitHub Actions

Code

# .github/workflows/seo-regression.yml
name: Regresja SEO
 
on:
  pull_request:
    branches: [main]
 
jobs:
  seo-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
 
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
 
      - run: npm ci
      - run: npx playwright install --with-deps chromium
 
      # Build i start aplikacji w tle
      - run: npm run build
      - run: npm start &
      - run: npx wait-on http://localhost:3000
 
      # Tylko testy SEO — szybko i celowo
      - run: npx playwright test tests/seo

Automatyczne testy regresji SEO w GitHub Actions — noindex, canonical i redirecty pod kontrolą CI/CD

Dlaczego SEO też zasługuje na testy regresji

Co dokładnie testować

Testy metadanych w Playwright

Testy przekierowań

Wpięcie w GitHub Actions

Czytaj dalej

Automatyczne testy regresji SEO w GitHub Actions — noindex, canonical i redirecty pod kontrolą CI/CD

Dlaczego SEO też zasługuje na testy regresji

Co dokładnie testować

Testy metadanych w Playwright

Testy przekierowań

Wpięcie w GitHub Actions

Czytaj dalej