Programmatic SEO w WordPressie: jak generować podstrony, które zostaną w indeksie

Programmatic SEO działa wtedy, gdy każda wygenerowana podstrona odpowiada na inne pytanie i ma czym odpowiedzieć. Jeśli danych nie starcza na wypełnienie szablonu, podstrona nie powinna w ogóle powstać. Cała reszta tego artykułu to konsekwencje tego jednego zdania: jak zbudować strukturę na WordPressie, jak wygląda szablon, jak policzyć próg, poniżej którego strona nie idzie do indeksu, i co robić, kiedy Google już usunął wygenerowane adresy.

Piszę o WordPressie, bo prawie każdy poradnik na ten temat wysyła czytelnika do Webflow, Airtable albo innego narzędzia zewnętrznego. Jeśli serwis stoi na WordPressie, migracja nie jest odpowiedzią.

TL;DR

Programmatic SEO (w skrócie pSEO) to generowanie wielu podstron z jednego szablonu i uporządkowanego zbioru danych.
Ryzykiem nie jest sama automatyzacja, tylko generowanie stron, które nie mają czym się od siebie różnić.
Na WordPressie fundamentem są własne typy treści i taksonomie, a nie wtyczka do masowego tworzenia stron.
Kluczowa decyzja to próg jakości: reguła, która przed publikacją rozstrzyga, czy dana podstrona ma prawo trafić do indeksu.
Jeśli Google już wyrzucił wygenerowane adresy, kolejność ratunku jest odwrotna do intuicji: najpierw odcięcie słabych podstron, dopiero potem poprawa reszty.

Spis treści

Programmatic SEO: co to jest i czym różni się od zwykłego SEO
Czy programmatic SEO jeszcze działa
Programmatic SEO na WordPressie: wtyczka czy własne typy treści
Szablon podstrony, którą da się obronić
Dane: skąd je wziąć i jak połączyć z szablonem
Generowanie treści z AI bez produkcji śmieci
Kiedy Google usuwa wygenerowane podstrony z indeksu
Dla jakiego serwisu programmatic SEO ma sens
Wnioski: kolejność wdrożenia
FAQ

Programmatic SEO: co to jest i czym różni się od zwykłego SEO

Programmatic SEO to tworzenie wielu podstron z jednego szablonu, zasilanego uporządkowanym zbiorem danych. Zamiast pisać ręcznie sto tekstów, przygotowujesz jeden układ strony i sto zestawów danych, a system składa z tego sto adresów.

Klasyczne SEO pracuje na pojedynczej stronie: jeden temat, jedna intencja, jeden tekst pisany przez człowieka. pSEO pracuje na wzorcu: jedna intencja powtarzalna w wielu wariantach, sto tekstów składanych automatycznie. Różnica nie polega na tym, że jedno jest ręczne, a drugie automatyczne. Polega na tym, że w pSEO projektujesz regułę, a nie treść.

Kiedy wzorzec faktycznie istnieje

Wzorzec istnieje wtedy, gdy potrafisz zapisać intencję użytkownika jako zdanie z lukami, a każde wypełnienie luk daje inne, sensowne pytanie.

„Gdzie w [dzielnica] zjem [rodzaj kuchni]” to wzorzec. Sto wypełnień daje sto różnych pytań, na które są różne odpowiedzi.

„Dlaczego warto wybrać [nazwa firmy]” wzorcem nie jest. Sto wypełnień daje sto razy ten sam tekst z podmienioną nazwą.

To rozróżnienie jest całą diagnozą przed projektem. Jeśli po wypełnieniu luk odpowiedzi są takie same, nie ma czego generować.

pSEO a SEO semantyczne

Te dwa podejścia bywają zestawiane jako przeciwieństwa, choć rozwiązują różne problemy. SEO semantyczne porządkuje relacje między tematami i encjami: co jest nadrzędne, co pomocnicze, co z czym się łączy. Programmatic SEO to sposób produkcji stron. Można mieć jedno bez drugiego, ale wdrożenie bez warstwy semantycznej zwykle kończy się zbiorem podstron, które konkurują ze sobą o to samo zapytanie.

Dobrze zaprojektowany katalog korzysta z obu: semantyka mówi, które poziomy zasługują na własny adres, a mechanizm generowania te adresy produkuje.

Czy programmatic SEO jeszcze działa

Tak, ale zmieniło się to, co Google uznaje za nadużycie. W wytycznych dla webmasterów opisane są dwie kategorie, które dotyczą tego tematu wprost: skalowane nadużywanie treści oraz strony przejściowe (doorway pages). Warto je przeczytać w oryginale, bo to jedyne wiążące źródło w całej dyskusji, a nie cudza interpretacja.

Sens obu zapisów da się streścić tak: problemem nie jest automatyzacja ani liczba stron, tylko brak wartości dla użytkownika. Strona wygenerowana automatycznie, ale odpowiadająca na realne pytanie kompletem danych, nie łamie żadnej reguły. Strona napisana ręcznie, ale będąca kolejnym wariantem tego samego tekstu, łamie ją mimo ludzkiego autorstwa.

Gdzie przebiega granica

Praktyczne kryterium, którego używam przy ocenie takich projektów: czy podstrona odpowiada na pytanie, którego nie zadaje żadna inna podstrona w serwisie, i czy ma na nie odpowiedź.

Pierwsza część chroni przed kanibalizacją. Druga przed pustymi stronami. Obie muszą być spełnione naraz.

Strony przejściowe to osobny przypadek: adresy istniejące wyłącznie po to, żeby złapać zapytanie i przerzucić użytkownika gdzie indziej. Klasyczny objaw to setki podstron miejscowości, które różnią się wyłącznie nazwą miasta i prowadzą do tego samego formularza. Tu nie pomoże żaden próg jakości, bo problem jest w założeniu, nie w wykonaniu.

Programmatic SEO na WordPressie: wtyczka czy własne typy treści

To pierwsze rozstrzygnięcie techniczne i najczęstsze miejsce, w którym projekt skręca w złą stronę.

Co potrafią wtyczki do generowania podstron

Wtyczki do masowego tworzenia stron sprawdzają się w jednym scenariuszu: jednorazowy import skończonego zbioru, gdzie każda pozycja ma być zwykłą stroną, a struktura nie będzie się już zmieniać. Importujesz plik, powstają strony, temat zamknięty.

Kończą się w momencie, w którym potrzebujesz czegokolwiek ponadto:

filtrowania i przeglądania po wielu wymiarach naraz,
automatycznych stron przeglądowych dla każdej kategorii i lokalizacji,
reguły, która decyduje o indeksacji pojedynczej pozycji,
ponownego przeliczenia wszystkiego po zmianie danych źródłowych.

Wtedy zamiast systemu masz kilka tysięcy zwykłych stron, których nie da się zbiorczo poprawić.

Własne typy treści i taksonomie

Fundamentem jest struktura danych, nie generator. Własny typ treści przechowuje pojedynczy obiekt, a taksonomie opisują wymiary, po których użytkownik będzie przeglądał zbiór. Archiwum taksonomii daje przy okazji stronę przeglądową dla każdego terminu, bez pisania osobnego szablonu.

add_action( 'init', function () {

    register_post_type( 'obiekt', [
        'label'        => 'Obiekty',
        'public'       => true,
        'has_archive'  => true,
        'rewrite'      => [ 'slug' => 'obiekty', 'with_front' => false ],
        'supports'     => [ 'title', 'editor', 'thumbnail', 'custom-fields' ],
        'show_in_rest' => true,
    ] );

    register_taxonomy( 'lokalizacja', 'obiekt', [
        'label'             => 'Lokalizacje',
        'hierarchical'      => true,
        'rewrite'           => [ 'slug' => 'lokalizacja', 'with_front' => false ],
        'show_in_rest'      => true,
        'show_admin_column' => true,
    ] );

    register_taxonomy( 'rodzaj', 'obiekt', [
        'label'             => 'Rodzaje',
        'hierarchical'      => true,
        'rewrite'           => [ 'slug' => 'rodzaj', 'with_front' => false ],
        'show_in_rest'      => true,
        'show_admin_column' => true,
    ] );

} );

Parametr show_in_rest jest tu istotny z powodów praktycznych: bez niego nie opublikujesz ani nie zaktualizujesz niczego przez REST API, a przy kilku tysiącach pozycji panel administracyjny przestaje być realnym narzędziem pracy.

Taksonomia hierarchiczna (hierarchical) pozwala zbudować poziomy, na przykład województwo, miasto, dzielnica, i przy okazji daje sensowne okruszki nawigacyjne.

Elementor i szablony

Elementor nadaje się do zaprojektowania wyglądu szablonu, o ile korzystasz z jego szablonów dla typu treści, a nie budujesz każdej podstrony osobno. Granica jest prosta: jeden szablon dla całego typu treści to dobre użycie, tysiąc stron zbudowanych z bloków to zbiór, którego nie zaktualizujesz.

Przy większych zbiorach warto sprawdzić, ile zapytań do bazy generuje szablon na jednej podstronie. Konstrukcje wizualne bywają kosztowne, a przy kilku tysiącach adresów koszt renderowania przekłada się na budżet indeksowania.

Struktura adresów: co dostaje własny URL

Nie każda kombinacja zasługuje na adres. Reguła, która sprawdza się w katalogach: adres dostaje to, czego ktoś realnie szuka, resztę zostawiamy jako filtr bez własnego URL.

Poziom	Przykład adresu	Własny URL
pojedynczy obiekt	`/obiekty/nazwa-obiektu/`	tak
kategoria	`/rodzaj/warsztaty/`	tak
lokalizacja	`/lokalizacja/poznan/`	tak
kategoria plus lokalizacja	`/rodzaj/warsztaty/poznan/`	tak, jeśli jest odpowiednio dużo obiektów
trzy wymiary naraz	kategoria, miasto, dodatkowa cecha	nie, filtr
sortowanie i strony wyników	`?sort=`, `?strona=`	nie, filtr

Ostatnie dwa wiersze to najczęstsze źródło rozdmuchanego indeksu. Kombinacje filtrów potrafią wygenerować dziesiątki tysięcy adresów, z których żaden nie odpowiada na osobne pytanie.

Szablon podstrony, którą da się obronić

Szablon to miejsce, w którym rozstrzyga się, czy podstrony będą się od siebie różnić.

Co wspólne, a co zmienne

Element	Status	Uwaga
tytuł i nagłówek H1	zmienny	z danych, nie z szablonu
pierwszy akapit z odpowiedzią	zmienny	konkretne dane, nie ogólniki
tabela parametrów	zmienna	to główna wartość podstrony
sekcja „dla kogo”	zmienna	wynika z cech obiektu
sekcja „kiedy wybrać inny”	zmienna	odsyła do sąsiednich podstron
opis kategorii, do której należy	wspólny	ten sam dla całej gałęzi
wyjaśnienie metodologii, zastrzeżenia	wspólny	powtarzalny, ale nie udaje treści unikalnej
nawigacja, stopka, formularz	wspólny	poza obszarem treści

Proporcja ma znaczenie mniejsze, niż się zwykle sądzi. Ważniejsze jest, czy część zmienna zawiera odpowiedź, po którą użytkownik przyszedł. Podstrona z trzema zdaniami konkretu i jedną tabelą danych jest lepsza od dwóch tysięcy słów wypełniacza.

Sekcje, które odróżniają sąsiednie podstrony

Najprostszy sprawdzian jakości szablonu: otwórz dwie sąsiednie podstrony obok siebie i zaznacz wszystko, co jest identyczne. To, co zostanie niezaznaczone, jest jedynym powodem, dla którego obie mają istnieć.

Trzy sekcje, które zwykle ratują ten sprawdzian:

Dla kogo ta pozycja jest dobra. Wynika z cech obiektu, więc różni się naturalnie.
Kiedy wybrać inną. Wymusza porównanie i daje link wewnętrzny do sąsiedniej podstrony.
Czym różni się od podobnych. Krótka tabela z dwiema, trzema alternatywami.

Ta sama zasada dotyczy treści pisanych pod cytowalność przez systemy AI, co opisywałem szerzej w tekście o tym, jak sklep internetowy może być cytowany przez AI. Struktura, która pomaga użytkownikowi wybrać, jest też tą, którą łatwo zacytować.

Dane: skąd je wziąć i jak połączyć z szablonem

Jakość projektu jest ograniczona jakością danych. Żaden szablon nie naprawi zbioru, w którym brakuje połowy pól.

Źródła i ich ograniczenia

Źródło	Co zwykle daje	Czego nie daje
rejestr publiczny	nazwa, adres, identyfikatory, branża	opis, ocena, kontekst użycia
interfejs zewnętrznego serwisu	dane kontaktowe, godziny, współrzędne, zdjęcia	prawo do dowolnego użycia, stabilność pól
własna baza produktowa	parametry, ceny, dostępność	odpowiedź na pytanie „dla kogo to jest”
arkusz uzupełniany ręcznie	dokładnie to, czego brakuje	skalowalność

Każde źródło ma ten sam problem: pokrywa część pól, a nie wszystkie, i pokrywa je nierówno. Duże miasta mają komplet, mniejsze miejscowości mają trzy pola z dziesięciu. Przy interfejsach zewnętrznych dochodzi kwestia licencji, bo nie każde dane wolno przechowywać i wyświetlać u siebie bez ograniczeń.

Konsekwencja jest praktyczna: nie planuj zbioru na podstawie liczby rekordów, tylko na podstawie liczby rekordów kompletnych. To zwykle inna liczba i zwykle znacznie mniejsza.

Jak sprawdzić, ile masz naprawdę

Zanim ustalisz próg, policz rozkład kompletności w całym zbiorze. Bez tego wartość progu jest zgadywaniem. Poniższy skrypt uruchamiany przez WP-CLI wypisuje, ile pozycji mieści się w kolejnych przedziałach:

/**
 * Rozkład kompletności w całym zbiorze.
 * Uruchomienie: wp eval-file rozklad.php
 */
$ids = get_posts( [
    'post_type'      => 'obiekt',
    'post_status'    => [ 'publish', 'draft' ],
    'posts_per_page' => -1,
    'fields'         => 'ids',
] );

$kubelki = [];

foreach ( $ids as $id ) {
    $klucz = number_format( floor( pseo_kompletnosc( $id ) * 10 ) / 10, 1 );
    $kubelki[ $klucz ] = ( $kubelki[ $klucz ] ?? 0 ) + 1;
}

ksort( $kubelki );

foreach ( $kubelki as $prog => $ile ) {
    printf( "%s: %d pozycji%s", $prog, $ile, PHP_EOL );
}

Wynik zwykle wygląda tak, że przy jednej wartości jest wyraźne skupienie, a poniżej niej rozkład się rozjeżdża. To skupienie to twój realny zasób, a wszystko poniżej to zbiór do uzupełnienia albo do odrzucenia. Dopiero mając tę tabelkę przed oczami, warto rozstrzygać, gdzie postawić próg.

Czego dane nie dadzą

Danych opisowych, oceniających i porównawczych nie znajdziesz w żadnym rejestrze. Zdanie „ta pozycja sprawdzi się, kiedy zależy ci na X, a odpadnie, kiedy potrzebujesz Y” trzeba wyprowadzić z posiadanych pól albo dopisać samodzielnie.

To jest ta część, której nie da się w pełni zautomatyzować i jednocześnie ta, która decyduje o przewadze nad konkurencją, bo prawie nikt jej nie robi.

Czym to spiąć

Przy zbiorze do kilkuset pozycji arkusz i import w zupełności wystarczą. Powyżej tego progu potrzebna jest baza i skrypt, który uruchamiasz ponownie po każdej zmianie danych. Kryterium wyboru nie jest wielkość zbioru, tylko częstotliwość aktualizacji: jeśli dane zmieniają się co miesiąc, ręczny import przestaje mieć sens znacznie wcześniej.

Generowanie treści z AI bez produkcji śmieci

Model językowy dobrze wykonuje jedno zadanie: zamienia komplet danych w poprawne zdanie. Źle wykonuje inne: udaje, że ma dane, których nie dostał.

Z tego wynika cała reguła korzystania z AI w takim projekcie. Model dostaje wypełnione pola i pisze z nich akapit. Model nie dostaje pustych pól z poleceniem „napisz coś”.

Co można oddać modelowi

przekształcenie parametrów w czytelny akapit,
ujednolicenie stylu opisów pochodzących z różnych źródeł,
wygenerowanie sekcji porównawczej na podstawie danych dwóch obiektów,
skrócenie zbyt długiego opisu z zachowaniem faktów.

Czego nie oddajemy: ocen, rekomendacji i wszystkiego, co wymaga wiedzy spoza przekazanych danych. Model wypełni to prawdopodobnym tekstem, który brzmi dobrze i bywa nieprawdziwy.

Weryfikacja przed publikacją, nie po

Kolejność ma znaczenie, bo poprawianie po publikacji oznacza, że wersja słaba zdążyła trafić do indeksu. Sensowny przebieg: dane, generowanie, kontrola progu jakości, publikacja. Kontrola jest krokiem osobnym i automatycznym, a nie czynnością redakcyjną wykonywaną wyrywkowo.

Publikację przy większych zbiorach wygodnie prowadzi się przez REST API WordPressa, co pozwala uruchomić cały przebieg ponownie po zmianie danych źródłowych. Warunkiem jest wspomniane wcześniej show_in_rest przy rejestracji typu treści i taksonomii.

Kiedy Google usuwa wygenerowane podstrony z indeksu

To scenariusz, o którym poradniki milczą, a który zdarza się najczęściej kilka miesięcy po wdrożeniu.

Objawy w Search Console

Wypadnięcie z indeksu ma dość charakterystyczny przebieg. W raporcie indeksowania rośnie liczba adresów w stanach „wykryto, ale jeszcze nie zindeksowano” oraz „przeskanowano, obecnie bez indeksu”. Liczba stron ważnych spada, choć nic nie usuwałeś. Wyświetlenia lecą w dół szybciej niż pozycje, bo znikają całe grupy adresów, a nie pojedyncze rankingi.

Sygnał, który odróżnia ten przypadek od zwykłego spadku: dotyka całych gałęzi struktury naraz, a nie pojedynczych podstron rozrzuconych po serwisie.

Próg jakości jako reguła policzalna

Próg jakości to funkcja, która przed publikacją odpowiada na pytanie, czy dana podstrona ma komplet potrzebny do bycia użyteczną. Poniżej przykład najprostszej wersji, liczącej udział wypełnionych pól wymaganych:

/**
 * Zwraca kompletność danych podstrony w skali od 0 do 1.
 */
function pseo_kompletnosc( $post_id ) {

    $wymagane = [ 'adres', 'godziny', 'kontakt', 'opis_wlasny', 'zdjecie' ];
    $wypelnione = 0;

    foreach ( $wymagane as $pole ) {
        if ( '' !== trim( (string) get_post_meta( $post_id, $pole, true ) ) ) {
            $wypelnione++;
        }
    }

    return $wypelnione / count( $wymagane );
}

/**
 * Podstrony poniżej progu nie trafiają do indeksu, ale przekazują linki dalej.
 */
add_action( 'wp_head', function () {

    if ( ! is_singular( 'obiekt' ) ) {
        return;
    }

    if ( pseo_kompletnosc( get_the_ID() ) < 0.6 ) {
        echo '<meta name="robots" content="noindex,follow">' . "\n";
    }

}, 1 );

Wartość progu ustala się na własnych danych, a nie z tabeli w internecie. Sposób, który daje sensowny punkt startu: policz kompletność dla całego zbioru, posortuj rosnąco i obejrzyj po dziesięć podstron przy kolejnych wartościach. Próg leży tam, gdzie sam przestajesz uznawać podstronę za użyteczną.

Kryteria warte uwzględnienia poza samą liczbą pól:

Kryterium	Dlaczego
komplet pól wymaganych	bez tego nie ma czym wypełnić szablonu
obecność treści opisowej spoza rejestru	odróżnia od kopii danych publicznych
liczba obiektów na stronie przeglądowej	strona z jednym wynikiem rzadko jest użyteczna
różnica wobec podstrony nadrzędnej	jeśli pokrywa się w całości, wystarczy nadrzędna

Co robić z podstronami poniżej progu

Cztery możliwe decyzje, w kolejności od najlżejszej:

Publikuj z noindex,follow. Strona zostaje dla użytkowników i przekazuje linki, ale nie zaśmieca indeksu.
Scal z podstroną nadrzędną. Sensowne przy kombinacjach, które mają za mało obiektów.
Ustaw adres kanoniczny na nadrzędną. Właściwe dla wariantów sortowania i filtrów.
Nie generuj wcale. Najlepsze rozwiązanie, jeśli braki danych są trwałe.

Czwarta opcja jest najczęściej pomijana, a najskuteczniejsza. Strona, która nigdy nie powstała, nie wymaga później sprzątania.

Jak wychodzić z deindeksacji

Kolejność jest odwrotna do intuicji. Naturalny odruch to poprawianie treści, ale dopóki w serwisie zostaje duża grupa słabych adresów, poprawa pojedynczych podstron niewiele zmienia.

Zdiagnozuj zasięg. Sprawdź w Search Console, które gałęzie struktury wypadły i czy pokrywają się z gałęziami o najniższej kompletności danych.
Odetnij słabe podstrony. Zastosuj próg jakości do całego zbioru i przenieś wszystko poniżej progu do noindex albo usuń.
Popraw to, co zostało. Uzupełnij dane, dodaj sekcje odróżniające, popraw linkowanie wewnętrzne.
Zgłoś ponownie. Zaktualizuj mapę witryny, tak żeby zawierała wyłącznie adresy przeznaczone do indeksowania.
Obserwuj przez kilka tygodni. Odbudowa indeksacji rzadko bywa natychmiastowa i zwykle idzie gałęziami, a nie równomiernie.

Uczciwe zastrzeżenie: nie ma gwarancji powrotu ani przewidywalnego terminu. Można poprawić przyczyny i zwiększyć szansę, ale każdy, kto obiecuje konkretną datę odbudowy indeksacji, zgaduje.

Dla jakiego serwisu programmatic SEO ma sens

Katalogi i serwisy lokalne

Najlepszy scenariusz. Wymiar geograficzny i kategoryjny dają naturalny wzorzec, dane bywają dostępne publicznie, a intencja użytkownika jest powtarzalna i wyraźnie różna dla każdej kombinacji.

Wzorzec, który działa: kategoria plus lokalizacja, przy progu kilkunastu obiektów na kombinację. Poniżej tego progu strona przeglądowa pokazuje trzy wyniki i nie daje użytkownikowi wyboru, więc lepiej ją scalić z poziomem nadrzędnym.

Wzorzec, który nie działa: lokalizacja plus usługa w modelu ogólnopolskim, gdzie firma obsługuje wszystkie miasta tak samo. To są strony przejściowe, niezależnie od tego, jak dobrze napisane.

Sklepy internetowe

Sprawdza się na poziomie kategorii, podkategorii i zestawień typu „produkty do zastosowania X”, nie na poziomie kart produktów. Karty produktów rzadko wymagają generowania, bo mają własne dane i własną intencję.

Najczęstszy sensowny wzorzec w sklepie to przecięcie parametru z zastosowaniem, na przykład kategoria plus konkretna cecha techniczna, o ile jest po niej realne wyszukiwanie i o ile masz w niej odpowiednio dużo produktów. Wymiar, który prawie nigdy się nie broni, to kolor i cena, bo to są filtry, a nie odrębne pytania.

SaaS i serwisy produktowe

Typowe wzorce to strony integracji, porównania z alternatywami i zastosowania branżowe. Warunek jest jednak trudniejszy do spełnienia: każda strona musi zawierać realną wiedzę o danym przypadku, a nie tę samą treść z podmienioną nazwą.

Strony integracji bronią się wtedy, gdy opisują, co konkretnie przepływa między systemami i czego ta integracja nie obsługuje. Zastosowania branżowe bronią się wtedy, gdy zawierają rzeczy specyficzne dla branży: nazewnictwo, typowy proces, ograniczenia prawne. Jeśli jedyną różnicą jest nazwa branży w nagłówku, wzorzec jest pozorny.

Kiedy odpuścić

Zbiór nie ma więcej niż kilkadziesiąt kompletnych rekordów. Napisz te strony ręcznie, wyjdzie szybciej i lepiej.
Wymiary nie zmieniają odpowiedzi, a jedynie nazwę w nagłówku.
Dane pochodzą wyłącznie z publicznego rejestru i nie masz czym ich uzupełnić. Kopia rejestru nie jest powodem, żeby to twoja strona była w wynikach.
Serwis ma nierozwiązane problemy techniczne. Tysiąc nowych adresów je pogłębi, a nie przykryje.

Wnioski: kolejność wdrożenia

Zapisz intencję jako zdanie z lukami i sprawdź, czy wypełnienia dają różne pytania.
Policz nie rekordy, tylko rekordy kompletne. Ta liczba wyznacza realną skalę projektu.
Zaprojektuj strukturę: własny typ treści, taksonomie, poziomy adresów.
Rozstrzygnij, które kombinacje dostają własny adres, a które zostają filtrem.
Zbuduj jeden szablon i sprawdź go na dwóch sąsiednich podstronach ustawionych obok siebie.
Dopisz dane opisowe, których nie ma w źródle. To jest przewaga, nie dodatek.
Zdefiniuj próg jakości na własnym zbiorze i zaimplementuj go jako regułę, nie jako zalecenie.
Wygeneruj partię próbną, na przykład pięćdziesiąt podstron, i obejrzyj wynik przed resztą.
Publikuj etapami, kontrolując indeksację po każdej partii.
Po sześciu do ośmiu tygodni sprawdź, które gałęzie się przyjęły, i dopiero wtedy skaluj dalej.

Jeśli planujesz taki projekt albo masz za sobą wdrożenie, które wypadło z indeksu, napisz do mnie. Zaczynamy od przeglądu danych i struktury adresów, bo to tam zwykle leży przyczyna, a nie w treści.

FAQ

Czy programmatic SEO jeszcze działa?

Tak, przy założeniu, że każda wygenerowana podstrona odpowiada na inne pytanie i ma czym odpowiedzieć. Wytyczne Google nie zabraniają automatyzacji ani dużej liczby stron, tylko publikowania treści bez wartości dla użytkownika. Zmieniło się to, że próg tolerancji dla stron pustych jest dziś wyraźnie niższy niż kilka lat temu.

Czy Google karze za automatycznie generowane podstrony?

Sposób powstania treści nie jest kryterium. Kryterium jest wartość i to, czy strona nie istnieje wyłącznie po to, żeby przechwycić zapytanie. Strona wygenerowana z kompletu danych, odpowiadająca na realne pytanie, mieści się w wytycznych. Setki wariantów tego samego tekstu z podmienioną nazwą miasta nie mieszczą się, niezależnie od tego, czy napisał je człowiek.

Czy da się to zrobić na WordPressie bez pisania kodu?

Częściowo. Import danych, własne pola i szablony da się poskładać z gotowych narzędzi. Reguła progu jakości, czyli automatyczna decyzja o indeksacji pojedynczej podstrony, wymaga już kilku linijek w motywie lub wtyczce. To zwykle najmniejsza część projektu i jednocześnie ta, która decyduje o wyniku.

Która wtyczka nadaje się do generowania podstron?

Wtyczki do masowego tworzenia stron sprawdzają się przy jednorazowym imporcie skończonego zbioru. Przy strukturze wielowymiarowej, aktualizowanych danych i regule indeksacji fundamentem powinny być własne typy treści i taksonomie, a wtyczka co najwyżej narzędziem do importu. Wybór wtyczki jest znacznie mniej istotny niż projekt struktury.

Ile podstron to za dużo?

Nie ma uniwersalnej liczby. Właściwe pytanie brzmi: ile masz rekordów kompletnych. Jeśli z pięciu tysięcy pozycji komplet danych ma osiemset, to osiemset jest twoją skalą, a pozostałe cztery tysiące to zobowiązanie na przyszłość, nie zasób.

Co zrobić, gdy Google usunął wygenerowane strony z indeksu?

Najpierw odetnij podstrony poniżej progu jakości, dopiero potem poprawiaj resztę. Odwrotna kolejność zwykle nie działa, bo duża grupa słabych adresów obciąża cały serwis. Po odcięciu popraw pozostałe, zaktualizuj mapę witryny i obserwuj przez kilka tygodni. Terminu odbudowy nie da się przewidzieć.

Czy treści na takie podstrony może napisać AI?

Do przekształcenia danych w czytelne zdania tak. Do wymyślania faktów, których w danych nie ma, nie. Praktyczna zasada: model dostaje wypełnione pola i pisze z nich akapit, a nie dostaje pustych pól z poleceniem, żeby coś napisał. Weryfikacja idzie przed publikacją, nie po niej.

Czym programmatic SEO różni się od zwykłego pozycjonowania?

Zakresem decyzji. W klasycznym SEO optymalizujesz pojedynczą stronę pod konkretną intencję. W programmatic SEO projektujesz regułę, która wyprodukuje setki stron, więc błąd w regule mnoży się przez liczbę adresów. Dlatego więcej czasu zajmuje tu projektowanie struktury i progu jakości niż samo pisanie.