Audyt treści z AI pod strony filarowe: jak uporządkować bloga pod topical authority

Artykuł dotyczy audytu treści AI związanego z tematem autorytetu tematycznego. Jeśli chcesz wiedzieć więcej, skąd wzięło się to podejście, opisuję to w artykule o autorytecie tematycznym.

Na czym polega audyt treści z AI i co robi w nim agent

Wprowadzenie porządku w zbiorze artykułów to w dużej mierze praca opierająca się na czytaniu. Należy przejrzeć wszystkie teksty, pogrupować je, znaleźć luki i nakładki, a potem nanieść zmiany w plikach. W tej pracy agent AI działający na repozytorium może ograniczyć czas ręcznego przeglądania i porządkowania plików. Ostatecznie decyzje nadal podejmujesz Ty, ale by je podjąć, nie musisz już samodzielnie czytać dwustu plików MDX. Ten artykuł opisuje cały proces, zaczynając od audytu, przez wybór strony filarowej i przypisanie wpisów do klastrów, po linkowanie, JSON-LD i kontrolę nad tym, co agent zmienia. Audyt treści uzupełnia w ten sposób artykuł o audycie technicznym SEO, który głównie koncentruje się na tym, czy roboty mogą dotrzeć do stron i je zrozumieć.

Kiedy porządkować istniejący blog, a kiedy zacząć od mapy tematów?

Porządkowanie ma sens, gdy istniejące treści mają jakąś wartość, której nie chcesz stracić, czyli oznacza to ruch z wyszukiwarki, linki zewnętrzne, pozycje na konkretne frazy. Wtedy każdy wpis jest materiałem do przypisania, połączenia albo rozbudowy, a nie do wyrzucenia.

Jeśli chodzi o samą mapę tematów, to zaczynamy wtedy, gdy wpisów jest mało (orientacyjnie kilka do kilkunastu), gdy nie przynoszą ruchu albo gdy strona zmienia profil i dotychczasowe teksty dotyczą tematów, w których nie chcesz już budować pozycji. Audyt i tak się przyda, ale będzie krótki i będzie obejmował, które artykuły zostawić, które przenieść do nowych klastrów, a które usunąć lub przekierować. W praktyce najczęstszy jest wariant mieszany. Blog ma dwa, trzy tematy, w których uzbierało się sporo tekstów, i kilka pojedynczych wpisów bez kontekstu. Wtedy porządkujesz istniejące skupiska, a dla nowych kierunków budujesz mapę od zera. Audyt robiony przez agenta dobrze pokazuje, który wariant będzie pasował do Twojej sytuacji.

Jak zlecić audyt treści agentowi AI: polecenie dla Claude Code i Codex

W sytuacji, kiedy masz już bloga lub serwis i chcesz w nim zrobić porządek, sprawa jest o tyle prostsza, że możesz użyć do pracy na przykład Claude Code albo Codex'a (lub innego agenta AI, jakiego preferujesz). Dobierasz model i dostępny poziom rozumowania do zakresu audytu, a potem stawiasz go przed zadaniem:

Dokonaj audytu treści i stwórz na jego podstawie mapę tematów (w pliku .md w projekcie), wskaż braki i oceń potencjał stworzenia stron pillarowych. Pytanie brzmi, czy możemy któryś z istniejących tekstów wybrać i ulepszyć do strony pillarowej, czy raczej stworzyć nową?

W rezultacie otrzymasz audyt, który określi, co wymaga poprawy, i wskaże kierunki rozwoju na przyszłość. To polecenie wystarczy na start, ale warto je także doprecyzować. Agent pracuje dokładnie na tym, co mu dasz, i sam nie wie, które wpisy przynoszą ruch. Dlatego lepsze wyniki daje wersja z danymi wejściowymi i narzuconym formatem wyjścia:

Przeprowadź audyt treści bloga. Pliki wpisów są w content/blog/*.mdx.
W docs/data/gsc-strony.csv jest eksport z Google Search Console
(strony, kliknięcia, wyświetlenia, średnia pozycja z ostatnich 12 miesięcy).
W docs/data/gsc-zapytania-strony.csv są dane łączące zapytania z URL-ami
i metrykami w podziale na miesiące, z tego samego okresu i typu wyszukiwania.
 
Na tym etapie niczego nie edytuj poza plikiem docs/audyt-tresci.md.
 
W pliku docs/audyt-tresci.md przygotuj:
1. Tabelę wszystkich wpisów: slug, tytuł, główny temat, intencja,
   liczba słów, kliknięcia z GSC, data ostatniej aktualizacji.
2. Proponowane klastry tematyczne (3–8), każdy z krótkim opisem zakresu.
3. Dla każdego klastra: kandydat na stronę filarową (istniejący wpis
   albo nowy tekst) z uzasadnieniem.
4. Wpisy o nakładającym się zakresie i podejrzenia kanibalizacji.
   Oddziel podobieństwo treści od problemów widocznych w danych GSC.
5. Wpisy nieaktualne, niewyczerpujące tematu albo niepasujące do klastra.
6. Luki: tematy, których brakuje, żeby klaster był kompletny.
 
Przy każdej ocenie podaj, na czym ją opierasz. Jeśli czegoś nie wiesz,
napisz to wprost zamiast zgadywać.

Sam eksport zakładki „Strony” w Google Search Console nie ujawnia, na jakie konkretne frazy kluczowe wyświetlają się poszczególne adresy URL. Aby uzyskać relację łączącą zapytania z dedykowanymi podstronami, konieczne jest wykorzystanie Search Console API lub przygotowanie osobnych eksportów filtrowanych dla poszczególnych URL-i. Zwykłe, odseparowane od siebie zestawienia stron i słów kluczowych są w tym kontekście niewystarczające. Bez precyzyjnego powiązania tych danych agent AI może jedynie przypuszczać nakładanie się tematyki, lecz nie potwierdzi rzeczywistej kanibalizacji w wynikach wyszukiwania. Pamiętaj przy tym, że porównanie analizowanych okresów pomaga ocenić trendy, ale same dane GSC nie rejestrują 100% zapytań — m.in. ze względu na ograniczenia wynikające z ochrony prywatności użytkowników.

Jaki model i poziom rozumowania wybrać do audytu treści?

Audyt wymaga porównywania wielu tekstów i pilnowania spójnych kryteriów. Sprawdź wybrany model na próbce wpisów, porównując jego przypisania z własną oceną i danymi. Przy trudniejszych przypadkach możesz zwiększyć poziom rozumowania, jeśli model go obsługuje. Nie gwarantuje to trafnego wyniku, a czas i zużycie tokenów zależą również od długości materiału, narzędzi i liczby powtórzeń. Wynik audytu będzie kierował dalszą pracą, więc jego weryfikacja ma większe znaczenie niż sam wybór najwyższego ustawienia.

Przy dużych blogach lepiej dzielić analizę na mniejsze partie. O ich wielkości powinna decydować długość tekstów, dostępny kontekst modelu i zakres zadania, a nie sztywna liczba wpisów. Skuteczniejsze jest podejście, w którym dzielimy pracę per strona filarowa i satelity. W ten sposób wybieramy grupę np. 30 wpisów i łączymy je ze sobą, czyli pracujemy na znacznie mniejszej ilości danych naraz. W taki sposób sam porządkowałem bloga StriveLab, wyznaczając tematyczne strony filarowe i łącząc je z satelitami. I tak krok po kroku uporządkowałem całego bloga, dodając naturalne strony filarowe, chociaż muszę powiedzieć, że nie wszystkie z nich zaklasyfikowałem jako część filarów — ok. 20% nie zostało przypisanych i jest to całkowicie normalne.

Co powinien zawierać raport z audytu treści?

Dobry audyt to dokument roboczy i powinien zawierać:

• inwentarz treści, czyli tabelę wszystkich wpisów z tematem, intencją i danymi o ruchu,
• propozycję klastrów z opisem zakresu każdego z nich,
• kandydatów na strony filarowe z uzasadnieniem, dlaczego ten tekst, a nie inny,
• listę podejrzeń kanibalizacji, z rozróżnieniem podobieństwa treści i oznak szkodliwej konkurencji w danych,
• listę luk z tematami do napisania,
• listę do decyzji: teksty do połączenia, przekierowania, aktualizacji albo usunięcia.

Pamiętaj, czego agent nie widzi, bo nie zna linków zewnętrznych prowadzących do Twoich wpisów, jeśli nie dostanie eksportu z narzędzia do analizy linków. Nie wie też, które teksty są ważne biznesowo, bo na przykład domykają sprzedaż Twoich usług. Ocenia też jakość tekstu według własnych kryteriów, które nie zawsze pokrywają się z Twoimi. W związku z powyższym, sam audyt traktuj jako pomoc do podjęcia decyzji i przemyśl ją dobrze, szczególnie jeśli pojawił się pomysł usunięcia artykułu i połączenia go z innym — usunięcie adresu bez odpowiedniego przekierowania może sprawić, że linki zewnętrzne będą prowadziły do nieistniejącej strony. O tym piszę w dalszej części artykułu.

Strona filarowa: rozbudować istniejący artykuł czy napisać nowy?

To pytanie z Twojego polecenia jest w całym procesie najważniejsze: rozbudowa wpisu, który dobrze rankuje na wąską frazę, może mu zaszkodzić, a z kolei napisanie kolejnego tekstu o tym samym zakresie i dla tej samej potrzeby użytkownika może zwiększyć ryzyko kanibalizacji. Sam wspólny temat lub wyświetlanie dwóch URL-i na tę samą frazę nie dowodzi problemu. Sprawdź, jakie potrzeby zaspokajają teksty i jak zmieniają się ich wyniki dla konkretnych zapytań.

Prawidłowo zrobiona strona filarowa to tekst, który omawia temat szeroko, odpowiada na podstawowe pytania i kieruje do artykułów satelickich po szczegóły. W sytuacji, w której kandydat jest świetnym, ale wąskim poradnikiem, zwykle lepiej zostawić go jako satelitę.

Jest też trzecia opcja, którą warto rozważać, czyli połączenie dwóch lub trzech nakładających się wpisów w jedną stronę filarową. Wybierasz URL z najlepszymi danymi, przenosisz do niego wartościowe fragmenty pozostałych, a stare adresy przekierowujesz trwale (301) na nowy tekst. Może to pomóc, jeśli teksty rzeczywiście się zastępują, ale nie gwarantuje wzrostu widoczności. Nowa strona powinna odpowiadać potrzebom użytkowników trafiających pod stare adresy. Google odradza przekierowania na niepowiązany cel, które mogą zostać uznane za soft 404. Prawidłowe przekierowanie trwałe samo w sobie nie powoduje utraty PageRank, choć podczas przetwarzania zmian pozycje mogą się wahać. Gdy usuwasz treść bez odpowiedniego zamiennika, właściwą odpowiedzią jest 404 lub 410.

Agent przyda się tutaj na dwa sposoby. Po pierwsze, może zestawić kandydatów według kryteriów z tabeli, jeśli dostał dane z Search Console, informacje o linkach zewnętrznych i treść wpisów. Po drugie, może przygotować konspekt rozbudowy: które sekcje dopisać, które skrócić i przenieść do satelitów, żeby strona filarowa nie powtarzała ich treści. Samą decyzję podejmuj jednak samodzielnie i pamiętaj, że w takich sprawach co nagle, to po diable.

Jak przypisać wpisy do klastrów tematycznych?

Przypisanie zapisujesz we frontmatterze. Wystarczą dwa pola: identyfikator klastra i rola wpisu.

cluster: 'audyt-seo'
cluster_role: 'satellite' # albo 'pillar'

Kiedy treści są walidowane schematem (na przykład Zod w content collections Astro albo we własnym loaderze w Next.js), dopisz dozwolone wartości do schematu. Literówka w nazwie klastra zatrzyma wtedy build i mamy jasną informację o błędzie. Pełniejszy model danych, z intencją i encjami, pokazuję w poradniku o autorytecie tematycznym w Astro i Next.js.

const clusters = ['audyt-seo', 'astro', 'headless-cms', 'migracje'] as const
 
export const postSchema = z
  .object({
    // ...pozostałe pola frontmattera
    cluster: z.enum(clusters).optional(),
    cluster_role: z.enum(['pillar', 'satellite']).optional(),
  })
  .refine((post) => Boolean(post.cluster) === Boolean(post.cluster_role), {
    message: 'cluster i cluster_role muszą być ustawione razem albo pominięte',
  })

Przypisanie krok po kroku: tabela, przegląd i zmiany w plikach

Kolejność ma znaczenie. Najpierw agent dopisuje do pliku audytu tabelę przypisań: slug, klaster, rola, pewność (wysoka, średnia, niska) i jedno zdanie uzasadnienia. Ty przeglądasz tabelę i poprawiasz, co trzeba. Dopiero potem agent nanosi przypisania do plików. Poprawienie wiersza w tabeli to kilka sekund, a wycofywanie zmian z czterdziestu plików to już osobne zadanie. Poziom pewności deklarowany przez model pomaga ustalić kolejność przeglądu, ale nie jest pomiarem trafności. Sprawdź uzasadnienia także przy wysokiej pewności, a propozycje łączenia i usuwania tekstów zawsze oceń na podstawie treści oraz danych.

Przypadki graniczne: dwa klastry, brak klastra i kanibalizacja

• Wpis pasuje do dwóch klastrów. Decyduje główna intencja, czyli potrzeba użytkownika, na którą tekst odpowiada. Tę samą potrzebę mogą wyrażać różne frazy. Przykładowo tekst o migracji z WordPressa na Astro trafia do klastra o migracjach albo do klastra o Astro, zależnie od tego, czy czytelnik szuka sposobu na przeniesienie strony, czy wiedzy o frameworku.

• Wpis nie pasuje do żadnego klastra. Jest to normalne, ponieważ ogłoszenia, podsumowania roku czy teksty okolicznościowe mogą zostać bez klastra. Jeśli wiele takich wpisów ma wspólny temat i przynosi ruch, sprawdź, czy uzasadniają utworzenie kolejnego klastra.

• Wpis jest za szeroki. Jeśli agent nie potrafi przypisać tekstu, bo porusza trzy tematy naraz, być może trzeba go podzielić albo zawęzić.

• Dwa wpisy o tym samym. Sprawdź, czy odpowiadają na tę samą potrzebę i czy w danych widać szkodliwą konkurencję. Dopiero potem zdecyduj, czy je połączyć, rozdzielić ich zakres, czy pozostawić jako uzupełniające się teksty.

Zasada „jeden wpis, jeden klaster”

Pole cluster przyjmuje jedną wartość i jest to świadome ograniczenie tego modelu, które upraszcza nawigację i reguły walidacji. Trzeba pamiętać, że nie jest to wymóg SEO, ponieważ Google dopuszcza kilka ścieżek breadcrumbs dla jednej strony. Wielokrotne przypisania też można uporządkować, ale wymaga to dodatkowych reguł.

Oczywiście powyższa zasada dotyczy przynależności, a nie linkowania. Tekst z klastra o migracjach może i powinien linkować do tekstów z klastra o Astro, jeśli czytelnikowi się to przyda (cały czas kierujemy się tak naprawdę interesem użytkownika). Chodzi tylko o to, żeby każdy przypisany wpis miał jeden „dom”.

Linkowanie wewnętrzne między stroną filarową a artykułami satelickimi

Ta część nie powinna być problemem, a kiedy przypisania są już we frontmatterze, agent ma pełną informację, co z czym połączyć. Twoim zadaniem jest ustalić reguły.

Linki kontekstowe w treści artykułów

Podstawowy układ wygląda tak:

• strona filarowa linkuje do każdego satelity w miejscu, gdzie omawia jego temat, z opisowym anchorem,
• każdy satelita linkuje do strony filarowej, najlepiej w pierwszych akapitach, żeby czytelnik z wyszukiwarki od razu widział szerszy kontekst,
• satelity linkują do siebie nawzajem tam, gdzie wynika to z treści, a nie dla samego linkowania.

Link w zdaniu pozwala wyjaśnić czytelnikowi, dlaczego warto przejść do innego tekstu. Warto przy tym pamiętać, że Google zaleca opisowe anchory i linkowanie w kontekście, ale nie podaje uniwersalnej reguły, że taki link zawsze ma większą wagę rankingową niż link w bloku „Powiązane artykuły”. Komponent generujący listę satelitów na podstawie frontmattera też jest przydatny, bo aktualizuje się sam przy każdym nowym wpisie.

Pamiętaj, by przy zlecaniu tego agentowi podawać wprost, by nie zmieniał istniejących linków, nie dodawał więcej niż jednego linku do tego samego URL w jednym tekście, dopisywał link do istniejącego zdania albo dodaj jedno zdanie, a nie cały akapit. Kiedy zapomnisz o takich regułach, agent potrafi dopisać do strony filarowej rozbudowane streszczenia każdego satelity, a to właśnie dublowanie treści, którego nie chcesz.

Relacje isPartOf i hasPart w danych strukturalnych JSON-LD

Właściwości isPartOf i hasPart opisują relację część–całość. Schema.org dopuszcza je dla artykułów, ale samo przypisanie dwóch tekstów do klastra nie oznacza, że jeden jest częścią drugiego. Przy niezależnych wpisach można opisać ich przynależność do wspólnej kolekcji, zamiast deklarować, że satelity są częściami artykułu filarowego.

Poniższy przykład dotyczy publikacji, w której strona filarowa rzeczywiście reprezentuje całość wieloczęściowego poradnika, a satelity są jego częściami. Parametr partsOfPillar ustawiasz po ocenie tej relacji dla danego klastra; domyślnie funkcja niczego nie dodaje. Kod umieszczasz tam, gdzie już budujesz JSON-LD, na przykład w schema.ts.

export function clusterRelations(
  post: Post,
  allPosts: Post[],
  partsOfPillar = false,
) {
  if (!partsOfPillar || !post.cluster || !post.cluster_role) return {}
 
  const inCluster = allPosts.filter((p) => p.cluster === post.cluster)
  const articleId = (slug: string) => `${SITE_URL}/blog/${slug}#article`
 
  if (post.cluster_role === 'pillar') {
    return {
      hasPart: inCluster
        .filter((p) => p.cluster_role === 'satellite')
        .map((p) => ({ '@id': articleId(p.slug) })),
    }
  }
 
  if (post.cluster_role !== 'satellite') return {}
  const pillar = inCluster.find((p) => p.cluster_role === 'pillar')
  return pillar ? { isPartOf: { '@id': articleId(pillar.slug) } } : {}
}

Funkcja zakłada, że wpisy przeszły walidację schematu i liczby stron filarowych. Jej wynik dokładasz do obiektu Article lub BlogPosting, który już generujesz. Ważne, żeby @id był taki sam w miejscu, gdzie definiujesz dany artykuł, i w miejscu, gdzie się do niego odwołujesz.

Uczciwie trzeba dodać, czego się po tym spodziewać. Google nie dokumentuje wykorzystania relacji isPartOf i hasPart między artykułami ani w rankingu, ani w wynikach rozszerzonych. Relacje między stronami wyszukiwarka odczytuje przede wszystkim z linków w HTML. JSON-LD jest tu dodatkiem: kosztuje kilkanaście linii kodu, bo generuje się z frontmattera, utrzymuje spójny graf danych na całej stronie i może być odczytany przez parsery obsługujące te właściwości. Nie należy zakładać, że każdy system AI pobierający stronę wykorzysta te relacje. Nie ma jednak twardych danych, że samo w sobie przekłada się na widoczność.

Jak kontrolować zmiany wprowadzane przez agenta AI?

Agent, który w jednej sesji ma zmienić frontmatter w stu plikach, dopisać linki i przebudować schemat, zrobi to szybko. Może jednak wprowadzić zmiany, o które nie prosiłeś, a w diffie na trzy tysiące linii łatwo je przeoczyć. Kontrola opiera się na trzech rzeczach: etapach, przeglądzie diffu i walidatorach.

Praca etapami i małe commity

Podziel pracę tak, żeby każdy etap dało się przejrzeć w kilka minut:

1. Audyt bez edytowania wpisów, jedyny zmieniony plik to dokument audytu.
2. Przypisania we frontmatterze, jeden klaster na commit.
3. Rozbudowa lub napisanie strony filarowej, osobny commit.
4. Linki w treści, jeden klaster na commit.
5. Zmiany w schema.ts i komponentach, osobny commit.

Zasady, które mają obowiązywać w każdej sesji, zapisz w pliku instrukcji projektu: CLAUDE.md dla Claude Code, AGENTS.md dla Codex. Wystarczy kilka punktów: nie zmieniaj slugów ani dat publikacji, nie przepisuj treści poza wskazanymi sekcjami, linkuj tylko do istniejących wpisów, po każdej zmianie uruchom walidację.

Przegląd zmian w git diff

Zacznij od git diff --stat. Jeśli zadanie dotyczyło frontmattera w dwunastu plikach klastra, a zmienionych plików jest trzydzieści, wiesz, że coś poszło nie tak, zanim przeczytasz choćby jedną linię. Przy zmianach w tekście pomaga git diff --word-diff. Standardowy diff pokazuje cały akapit jako zmieniony, nawet gdy agent dopisał jeden link, a tryb słów pokazuje dokładnie, co się zmieniło. Na co patrzeć w pierwszej kolejności: zmienione daty, slugi i tytuły, przeredagowane zdania, o które nie prosiłeś, linki do adresów, których nie znasz.

Walidator spójności klastrów w buildzie i CI

Najlepiej, żeby walidator powstał przed zmianami. Poproś agenta, żeby najpierw napisał skrypt sprawdzający spójność klastrów, a dopiero potem wprowadzał przypisania i linki, przy czym skrypt uruchamiany w buildzie lub w CI powinien sprawdzać:

1. Czy każdy klaster ma dokładnie jedną stronę filarową?
2. Czy każdy satelita zawiera link do swojej strony filarowej?
3. Czy strona filarowa linkuje do wszystkich swoich satelitów?
4. Czy linki do wpisów prowadzą do istniejących slugów, a pozostałe linki wewnętrzne do prawidłowych tras serwisu?

Poniższy fragment sprawdza trzy pierwsze warunki dla klastrów obecnych we wpisach. Uruchamiasz go po walidacji frontmattera, która odrzuca niepełne przypisania. Post to typ wpisu w projekcie, a linksTo to funkcja analizująca linki w MDX i porównująca ich znormalizowane adresy z adresem wskazanego wpisu.

const errors: string[] = []
const grouped = new Map<string, Post[]>()
 
for (const post of allPosts) {
  if (!post.cluster) continue
  const posts = grouped.get(post.cluster) ?? []
  posts.push(post)
  grouped.set(post.cluster, posts)
}
 
for (const [cluster, posts] of grouped) {
  const pillars = posts.filter((p) => p.cluster_role === 'pillar')
  if (pillars.length !== 1) {
    errors.push(
      `${cluster}: oczekiwano 1 strony filarowej, jest ${pillars.length}`,
    )
    continue
  }
  const pillar = pillars[0]
  for (const sat of posts.filter((p) => p.cluster_role === 'satellite')) {
    if (!linksTo(sat, pillar.slug))
      errors.push(`${sat.slug}: brak linku do ${pillar.slug}`)
    if (!linksTo(pillar, sat.slug))
      errors.push(`${pillar.slug}: brak linku do ${sat.slug}`)
  }
}

Czwarty warunek wymaga osobnego sprawdzenia wszystkich linków wewnętrznych, także we wpisach bez klastra. Po zebraniu adresów z MDX porównaj linki do artykułów z listą opublikowanych slugów, a inne adresy z trasami serwisu. Uwzględnij adresy względne i bezwzględne oraz normalizację końcowego ukośnika. Błędy muszą kończyć skrypt niezerowym kodem wyjścia, żeby zatrzymać build lub CI.

Do tego dochodzi sprawdzenie wygenerowanych danych na kilku stronach w Schema Markup Validator. Narzędzie obsługuje JSON-LD, Microdata i RDFa oraz sprawdza użycie słownika Schema.org. Nie potwierdza prawdziwości opisanych relacji, spójności całego serwisu ani kwalifikacji do wyników rozszerzonych Google. Walidatory wykrywają błędy objęte ich regułami; sens linkowania i poprawność relacji nadal oceniasz podczas przeglądu.

Lista kontrolna audytu treści i stron filarowych

• Dane stron i powiązanych z nimi zapytań z Google Search Console przygotowane do analizy, z porównaniem okresów.

• Audyt wykonany bez edytowania wpisów, zapisany w pliku .md.

• Klastry zdefiniowane i opisane, 3–8 na start.

• Dla każdego klastra decyzja: rozbudowa, nowy tekst albo połączenie wpisów z przekierowaniem 301.

• Tabela przypisań przejrzana ręcznie, z kontrolą uzasadnień także przy wysokiej pewności deklarowanej przez model.

• Pola cluster i cluster_role dodane do schematu frontmattera z listą dozwolonych wartości.

• Przypisania naniesione, jeden klaster na commit.

• Strona filarowa linkuje do wszystkich satelitów, każdy satelita do strony filarowej.

• Relacje isPartOf i hasPart, jeśli dodane, opisują rzeczywistą strukturę publikacji i wskazują spójne identyfikatory @id.

• Skrypt spójności klastrów uruchamiany w buildzie lub w CI.

• JSON-LD sprawdzony w walidatorze na kilku stronach.

• Reguły dla agenta zapisane w CLAUDE.md lub AGENTS.md.