Bloki powiązanych treści: Zasady linkowania wewnętrznego

Blok powiązanych treści to krótki, ręcznie wybrany zestaw linków umieszczany na końcu głównej treści. Prowadzi czytelnika do najbardziej przydatnej następnej strony i przekazuje autorytet wewnętrzny wzdłuż tego samego linku. Każda strona docelowa musi mieć redakcyjny powód swojego istnienia; same wspólne tagi nie wystarczą.

Wyrenderowany przykład jest celowo skromny. Jego nagłówek wyjaśnia wybór, każda kotwica przewiduje miejsce docelowe, a każdy powód mówi czytelnikowi, dlaczego ta strona jest następna. Blok nie konkuruje z artykułem, który podsumowuje.

Dlaczego ten element jest ważny

Skończenie użytecznej strony tworzy punkt decyzyjny. Czytelnik może rozumieć dany temat, ale wciąż potrzebować go zastosować, porównać opcje, poznać wymagania wstępne lub przejść w kierunku produktu. Blok powiązanych treści zmniejsza wysiłek znalezienia tego następnego kroku. Oferuje mały zestaw celowych ścieżek w momencie, gdy czytelnik jest gotowy do wyboru, zamiast prosić go o powrót do globalnej nawigacji lub ponowne wyszukiwanie.

Drugie zadanie ma charakter architektoniczny. Autorytet wewnętrzny to znaczenie i kontekstowa trafność, które linki pomagają dystrybuować między stronami w tej samej witrynie. Link tworzy krawędź między dwoma dokumentami. Jego pozycja, kotwica i wyjaśnienie mówią systemom wyszukiwania, co reprezentuje ta krawędź: która strona jest szerokim autorytetem, która obejmuje podtemat, a która odpowiada na pokrewną potrzebę.

Ekstrahowalność maszynowa oznacza, że zautomatyzowany system może odzyskać te relacje z kodu HTML bez zgadywania na podstawie układu. Semantyczny region nawigacyjny, widoczny nagłówek, zwykłe linki do przeszukiwania, opisowe kotwice i jeden element na stronę docelową ujawniają czysty zestaw stwierdzeń źródło–relacja–miejsce docelowe. Karuzele tylko w JavaScript, karty tylko z obrazem i ogólne kotwice zaciemniają te stwierdzenia, nawet gdy wyglądają elegancko.

Oba zadania muszą przetrwać przegląd. Blok, który zdobywa kliknięcia, ale wysyła autorytet do niepowiązanych stron, szkodzi modelowi treści; poprawna mapa klastra z nieistotnymi linkami marnuje punkt decyzyjny czytelnika.

Kiedy go używać

Użyj tego elementu, gdy strona ma od dwóch do pięciu wiarygodnych następnych miejsc docelowych, a relację można opisać w jednym zdaniu. Należy go stosować w edukacyjnych treściach evergreen, komercyjnych wyjaśnieniach, porównaniach, stronach produktów i kategorii, stronach przypadków użycia i studiach przypadków, gdy inna strona rzeczywiście rozwija to samo zadanie lub decyzję.

Nie dodawaj go tylko dlatego, że szablon ma puste miejsce. Strona jednotematyczna z jednym koniecznym działaniem może potrzebować tylko zamykającego wezwania do działania. Informacja prawna, ekran konta, zgłoszenie wsparcia lub krótka strona narzędziowa mogą nie mieć sensownej kontynuacji redakcyjnej. Indeks, którego główna treść już składa się z kart nawigacyjnych, nie potrzebuje drugiej listy je powtarzającej.

Typowe chybione przypadki obejmują:

• Kanał tagów odpowiada na pytanie „co ma tę samą etykietę?”, a nie „co ten czytelnik powinien zrobić dalej?”. Dwa artykuły oznaczone tagiem „analityka” mogą służyć różnym odbiorcom i etapom.
• Najnowsze wpisy nagradzają datę publikacji, a nie trafność. Aktualność jest przydatna w odkrywaniu wiadomości, ale nie jest modelem relacji.
• Popularne wpisy optymalizują pod kątem zagregowanego ruchu, a nie bieżącego pytania.
• Mapa witryny w stopce wspiera szerokie odkrywanie, a nie małą, redakcyjnie wybraną ścieżkę.
• Przycisk poprzedni/następny odzwierciedla kolejność publikacji. Ma znaczenie tylko wtedy, gdy ta kolejność jest sama w sobie celowym kursem lub sekwencją.
• Kontekstowe linki w tekście wyjaśniają terminy lub popierają twierdzenia w miejscu potrzeby. Uzupełniają ten blok, ale nie zastępują jego roli decyzyjnej na końcu strony.

Wybór jest domyślnie ręczny. Dla każdego proponowanego linku redaktor zapisuje powód, taki jak „stosuje metodę”, „definiuje wymaganie wstępne”, „porównuje dwie opcje wprowadzone tutaj” lub „pokazuje dowody w praktyce”. Jeśli powód brzmi po prostu „ten sam tag”, usuń element.

Automatyczny wybór jest dopuszczalny w archiwach wiadomości, kolekcjach generowanych przez użytkowników lub zasobach zbyt dużych i zmiennych do kuratorowania pozycja po pozycji. Nawet wtedy wymagaj kontrolowanego zestawu kandydatów, wykluczeń dla bieżącego adresu URL i wygasłych stron, świeżości tam, gdzie czas ma znaczenie, trafności wykraczającej poza jeden tag, stabilnego mechanizmu rozstrzygania remisów i nadzoru redakcyjnego.

Gdzie go umieścić

Umieść blok po zakończeniu głównej treści i po bloku źródeł, ale przed zamykającym wezwaniem do działania. Powód jest sekwencyjny: źródła zamykają obowiązek dowodowy bieżącej strony; powiązane treści oferują następną ścieżkę nauki lub oceny; końcowe wezwanie do działania oferuje ścieżkę komercyjną lub produktową. Gdy strona nie ma bloku źródeł, powiązane treści następują po końcowej sekcji merytorycznej.

Nie umieszczaj drugiego bloku powiązanych treści w innym miejscu na stronie. Nie sytuuj go obok zduplikowanej nawigacji poprzedni/następny, gęstej chmury tagów ani innej kolekcji zatytułowanej „Może Ci się również spodobać”. Jeden wyraźny region rekomendacji wystarczy.

Anatomia

Legenda wyrenderowana:

1. Nagłówek sekcji: nazywa relację, np. „Zastosuj to, czego się nauczyłeś” lub „Porównaj kolejne opcje”. Ogólne „Powiązane” jest dopuszczalne tylko wtedy, gdy miejsca docelowe rzeczywiście obejmują różne działania.
2. Tytuł elementu: dostarcza opisową kotwicę i przewiduje podstawową wartość miejsca docelowego.
3. Adres URL miejsca docelowego: prowadzi do jednego kanonicznego, przeszukiwalnego wewnętrznego adresu URL bez łańcucha przekierowań.
4. Miniatura: opcjonalnie odróżnia miejsce docelowe, gdy obraz niesie rzeczywiste informacje identyfikujące.
5. Powód w jednym zdaniu: opcjonalnie wyjaśnia, dlaczego ta strona jest logicznym następnym krokiem; zdecydowanie zalecany, gdy relacja nie jest oczywista z tytułu.
6. Granica bloku: grupuje linki jako nawigację, nie czyniąc całej karty niejednoznacznym celem kliknięcia.

Legenda należy do strony, a nie do wnętrza obrazu, aby pozostała zaznaczalna, przetłumaczalna i dostępna dla technologii asystujących.

Przykłady projektów

Warianty zmieniają gęstość informacji, a nie logikę redakcyjną.

Tylko tekst: domyślny, gdy tytuły miejsc docelowych jasno określają relację.

Z powodami: domyślny dla różnych etapów podróży. Powód dodaje relację, zamiast powtarzać tytuł.

Z miniaturami: zarezerwowany dla przypadków, gdy oryginalne obrazy pomagają w rozpoznawaniu. Obrazy potrzebują wymiarów i użytecznego tekstu alternatywnego lub pustego alternatywnego, gdy tytuł już nazywa miejsce docelowe.

Międzysfilarowy: ujawnia relacje między typami wpisów, elementami i zastosowaniami biznesowymi. Jest generowany ze zweryfikowanych danych frontmatter, a nie z tagów.

Parametry

Dwa elementy są dozwolone tylko wtedy, gdy strona ma wąski, wiarygodny rozwidlenie. Trzy do pięciu to normalny zakres: wystarczająco dużo wyboru, aby obsłużyć różne następne potrzeby, ale na tyle mało, aby każdy link pozostał widoczny i celowy. Sześć to twardy wyjątek dla filaru, który musi ujawnić kompletny mały klaster. Więcej niż sześć staje się katalogiem, osłabia redakcyjny sygnał każdej krawędzi i sprawia, że skanowanie mobilne jest kosztowne.

Pominięty atrybut tytułu może być pochodną pierwszego nagłówka w treści elementu. Nie podawaj obu z różnym tekstem. Powód może znajdować się w atrybucie dla prostego zdania lub w treści, gdy wymaga wyróżnienia w tekście; nie może wystąpić dwukrotnie.

Składnia i przykłady kodu

Kanoniczna nazwa komponentu to related-content. Zagnieżdżona forma ::item{} utrzymuje pola każdego miejsca docelowego razem i zapobiega rozjeżdżaniu się równoległych tablic.

Przenośna dyrektywa Markdown

:::related-content{heading="Continue with the playbook" variant="reason"}
::item{title="Write a reliable how-to guide" url="/seo-playbook/post-types/how-to-guide/" reason="Turn the element rules into a complete instructional page."}
::item{title="Structure an ultimate guide" url="/seo-playbook/post-types/ultimate-guide/" reason="Connect this element to a broad pillar and its supporting spokes."}
::item{title="Build a use-case page" url="/seo-playbook/post-types/use-case-page/" reason="Carry educational intent into a specific audience and outcome."}
:::

Shortcode Hugo

{{< related-content heading="Continue with the playbook" variant="reason" >}}
  {{< item title="Write a reliable how-to guide" url="/seo-playbook/post-types/how-to-guide/" reason="Turn the element rules into a complete instructional page." />}}
  {{< item title="Structure an ultimate guide" url="/seo-playbook/post-types/ultimate-guide/" reason="Connect this element to a broad pillar and its supporting spokes." />}}
  {{< item title="Build a use-case page" url="/seo-playbook/post-types/use-case-page/" reason="Carry educational intent into a specific audience and outcome." />}}
{{< /related-content >}}

Jest to przenośny docelowy kontrakt, a nie twierdzenie, że to repozytorium rejestruje shortcode. Przykład na żywo używa semantycznego HTML i nie dodaje zależności układu.

Blok lub shortcode WordPress

<!-- wp:amicited/related-content {"heading":"Continue with the playbook","variant":"reason"} -->
[related_item title="Write a reliable how-to guide" url="/seo-playbook/post-types/how-to-guide/" reason="Turn the element rules into a complete instructional page."]
[related_item title="Structure an ultimate guide" url="/seo-playbook/post-types/ultimate-guide/" reason="Connect this element to a broad pillar and its supporting spokes."]
[related_item title="Build a use-case page" url="/seo-playbook/post-types/use-case-page/" reason="Carry educational intent into a specific audience and outcome."]
<!-- /wp:amicited/related-content -->

WordPress powinien używać zarejestrowanego bloku dynamicznego z zagnieżdżonymi kontrolkami elementów. Forma shortcode jest przeznaczona dla systemów, które nie mogą przechowywać zagnieżdżonych bloków i musi być zarejestrowana przed publikacją.

Przykłady

Dobrze: każdy link odpowiada na inną następną potrzebę

:::related-content{heading="Put the method into practice" variant="reason"}
::item{title="Run the pre-publish QA checklist" url="/seo-playbook/process/checklists/pre-publish-qa/" reason="Verify links, evidence, accessibility, and page structure before release."}
::item{title="Build a how-to guide" url="/seo-playbook/post-types/how-to-guide/" reason="Apply the element inside a complete instructional format."}
::item{title="Adapt the playbook for SaaS" url="/seo-playbook/business-types/saas/" reason="Translate the shared rules into a product-led content journey."}
:::

Działa to, ponieważ miejsca docelowe są odrębne, ale połączone: weryfikacja, wdrożenie i adaptacja biznesowa. Kotwice określają, co dostarcza każda strona, a powody wyjaśniają relację z bieżącą stroną.

Źle: widżet tagów udający wybór redakcyjny

:::related-content{heading="You may also like"}
::item{title="Read more" url="/blog/new-office/"}
::item{title="Click here" url="/features/ai-visibility/"}
::item{title="Latest post" url="/blog/quarterly-roundup/"}
::item{title="SEO" url="/seo-playbook/"}
::item{title="More SEO" url="/blog/old-seo-notes/"}
::item{title="Another article" url="/academy/how-to-export-prompt-data/"}
::item{title="Recommended" url="/case-studies/hz-containers/"}
:::

Przykład jest nieudany, nawet jeśli każdy adres URL działa. Siedem opcji przekracza zakres. Kotwice nie przewidują miejsca docelowego. Miejsca docelowe mieszają intencje firmowych wiadomości, produktu, archiwum, akademii i studium przypadku bez podanych powodów. „Najnowszy” to reguła daty, „SEO” jest zbyt szerokie, a nic nie dowodzi, że linki służą następnemu zadaniu tego czytelnika.

Kontrakt klastra

Klaster tematyczny to zaplanowana grupa stron wokół jednego tematu. Jego filar to szeroka strona organizująca temat; jego szprychy to węższe strony odpowiadające na jego części. Blok powiązanych treści zamienia ten plan na rzeczywiste linki HTML:

• Każda szprycha linkuje w górę do swojego filaru. Mówi to czytelnikom, gdzie należy wąska odpowiedź i zapobiega przekształceniu szprychy w izolowany punkt końcowy.
• Filar linkuje w dół do każdej bieżącej szprychy. Gdy klaster ma więcej niż sześć szprych, używaj zorganizowanych sekcji w treści filaru, zamiast wymuszać pełny zestaw w jednym bloku powiązanych treści.
• Linki boczne łączą jedną szprychę z drugą tylko wtedy, gdy czytelnik może określić relację następnego kroku. Wspólny rodzic nie jest wystarczający.
• Każda krawędź jest dwukierunkowa, gdy oba kierunki pomagają czytelnikowi. Odwrotna kotwica i powód mogą się różnić, ponieważ podróż jest inna.
• Usunięcie, scalenie lub przekierowanie strony uruchamia przegląd każdej przechowywanej krawędzi, która do niej prowadzi.

W ramach tego playbooka strona typu wpisu linkuje do elementów, których wymaga, oraz do typów biznesowych, które ją adaptują. Strona elementu linkuje z powrotem do typów wpisów, które go używają. Te relacje są generowane ze zweryfikowanych danych frontmatter zgodnie z zasadami międzysfilarowymi: tablica postTypes tej strony jest źródłem jej linków do typów wpisów, podczas gdy odpowiednie metadane typu wpisu dostarczają krawędź zwrotną. Generowanie obsługuje renderowanie; redaktorzy wciąż decydują, czy relacja należy do metadanych.

Szersze zasady pisania elementów regulują, jak te metadane pozostają przenośne. Nigdy nie naprawiaj brakującej relacji redakcyjnej przez dodanie tagu i liczenie, że widżet wybierze prawidłowo.

Zasady dotyczące tekstu kotwicy

Tekst kotwicy to widoczne, klikalne sformułowanie linku. Napisz go tak, aby czytelnik mógł przewidzieć miejsce docelowe bez czytania adresu URL. „Zbuduj poradnik krok po kroku” jest użyteczne; „czytaj dalej”, „kliknij tutaj”, „dowiedz się więcej” i nagi adres URL nie są.

Urozmaicaj kotwice naturalnie, zachowując temat miejsca docelowego. „Utwórz poradnik krok po kroku” i „strukturyzuj instrukcję” działają; niepowiązane synonimy słów kluczowych nie. Nigdy nie obiecuj szablonu, kalkulatora, ceny, badania ani listy kontrolnej, których miejsce docelowe nie posiada.

Wewnątrz bloku kotwice tytułów powinny być unikalne. Jeśli dwa miejsca docelowe używałyby tego samego tytułu, dodaj rozróżniającą grupę odbiorców, metodę lub rezultat. Pozostaw opcjonalny powód poza kotwicą, aby cel kliknięcia pozostał zwięzły, a listy linków dla technologii asystujących pozostały użyteczne.

Znaczniki Schema i dostępność

Nie jest wymagany żaden specjalny typ JSON-LD. JSON-LD to oparty na skryptach format danych strukturalnych, a Schema.org to wspólne słownictwo zwykle kodowane za jego pomocą. Linki normalnie pozostają częścią otaczającego Article, TechArticle, Product lub WebPage. Nie wymyślaj typu schema RelatedContent.

ItemList może opisywać blok tylko wtedy, gdy jest to autentycznie uporządkowana lub nazwana lista redakcyjna, a strategia schema w całej witrynie tego wymaga. Jeśli używany, itemListElement musi odpowiadać widocznej kolejności elementów, adresom URL i nazwom. Nie dodawaj ukrytych miejsc docelowych ani sztucznych ocen. Breadcrumb to inna relacja i nie może wchłaniać tych linków.

Dostępność zaczyna się od punktu orientacyjnego <nav>, czyli regionu, który technologia asystująca może zidentyfikować jako nawigację. Nadaj mu widoczny nagłówek połączony przez aria-labelledby; ARIA to zestaw atrybutów używanych do ujawniania nazw i stanów interfejsu, gdy natywny HTML sam potrzebuje pomocy. Użyj <ul>, ponieważ kolejność normalnie nie niesie rangi. Zachowaj widoczny fokus klawiatury, uczyń tytuł głównym linkiem i unikaj zagnieżdżania interaktywnej karty wewnątrz innego linku.

Tekst alternatywny miniatur nie może powielać linkowanego tytułu. Użyj pustego tekstu alternatywnego dla ozdobnej miniatury. Gdy obraz wnosi odrębne informacje, opisz tylko te informacje. Blok musi pozostać kompletny z wyłączonymi obrazami lub JavaScript i nie może przesuwać fokusu klawiatury po odświeżeniu rekomendacji.

Zasady pisania

Używaj domyślnie od trzech do pięciu elementów, dwóch dla wąskiego rozwidlenia i nie więcej niż sześciu dla udokumentowanej potrzeby małego klastra. Napisz nagłówek od dwóch do ośmiu słów, kotwice tytułów od trzech do dwunastu słów i opcjonalne powody od ośmiu do dwudziestu dwóch słów. Powody używają jednego zdania, strony czynnej i konkretnej relacji: zastosuj, porównaj, zweryfikuj, zdefiniuj, diagnozuj lub zobacz dowody.

Każdy element potrzebuje odrębnego powodu redakcyjnego w modelu treści, nawet jeśli powód nie jest renderowany. Przeglądaj tytuły po zmianie nagłówków miejsc docelowych. Używaj kanonicznych wewnętrznych adresów URL z leading i trailing slash. Usuń parametry śledzenia, fragmenty, które nie identyfikują stabilnych sekcji, przekierowania i linki z powrotem do bieżącej strony.

Nigdy nie umieszczaj reklam, biografii autora, przycisków obserwowania w mediach społecznościowych, formularzy newslettera, chmur tagów, niepowiązanych promocji ani cytatów źródłowych wewnątrz tego elementu. Nie mieszaj zewnętrznych lektur z wewnętrznymi następnymi krokami; dowody zewnętrzne należą do bloku źródeł. Nie używaj odznak takich jak „najlepsze”, „popularne” lub „polecane”, chyba że strona definiuje i popiera podstawę wyboru.

Ton powinien być pomocny i konkretny, a nie naglący. Unikaj „musisz przeczytać”, „nie przegap”, sztucznej rzadkości i twierdzeń, że miejsce docelowe jest wyczerpujące, chyba że jego zakres uzasadnia to słowo. Blok rekomenduje ścieżkę; nie wytwarza ważności.

Typy wpisów, które go używają

Tablica postTypes w frontmatter jest źródłem prawdy dla następujących relacji międzysfilarowych.

Nie każdy kandydat musi być renderowany na każdej stronie. Typ wpisu definiuje kwalifikującą się relację; redaktor strony wybiera miejsca docelowe, które mają sens dla danego tematu i podróży.

Lista kontrolna QA

• Blok pojawia się raz, po źródłach i przed zamykającym wezwaniem do działania.
• Strona zawiera od dwóch do pięciu linków lub udokumentowany powód użycia sześciu.
• Każdy element ma zapisany powód redakcyjny wykraczający poza wspólny tag, kategorię lub datę publikacji.
• Każda kotwica przewiduje, co miejsce docelowe faktycznie dostarcza, i unika „czytaj dalej”, „kliknij tutaj” i podobnych ogólników.
• Zestaw wspiera kontrakt klastra: szprycha w górę, filar w dół i boczne tylko wtedy, gdy rzeczywiście powiązane.
• Bieżący adres URL jest wykluczony, miejsca docelowe są kanoniczne i żaden link nie opiera się na przekierowaniu lub parametrze śledzenia.
• Frontmatter powiązanych treści zgadza się z wyrenderowanymi linkami międzysfilarowymi.
• Blok pozostaje czytelny, nawigowalny i kompletny bez miniatur ani JavaScript.
• Region nawigacyjny ma widoczny nagłówek i dostępną nazwę; fokus klawiatury jest widoczny.
• Miniatury istnieją, dodają wartość identyfikującą, rezerwują wymiary i używają poprawnego tekstu alternatywnego.
• Powody dodają relację następnego kroku zamiast powtarzać tytuły.
• Źródła, reklamy, formularze, linki społecznościowe i niepowiązane promocje pozostają poza blokiem.
• Wszelkie dane strukturalne ItemList dokładnie odpowiadają widocznym elementom i kolejności.
• Renderowanie mobilne wyświetla każdy tytuł i powód bez ukrytej poziomej karuzeli.

Osoba recenzująca powinna odrzucać jedynie pozornie poprawne linki. Każdy z nich musi być właściwym następnym krokiem, wyrażać rzeczywistą krawędź architektoniczną i pozostawać jasny w HTML.

FAQ

Szablon akademii renderuje wpisy FAQ z frontmatter.