Relatert innhold-blokker: Regler for intern lenking

En relatert innhold-blokk er et kort, manuelt valgt sett med lenker plassert på slutten av hovedinnholdet. Den fører leseren til den mest nyttige neste siden og sender intern autoritet langs samme lenke. Hver destinasjon må ha en redaksjonell grunn til å eksistere; felles stikkord alene er ikke nok.

Det gjengitte eksemplet er bevisst beskjedent. Overskriften forklarer valget, hver ankertekst forutsier destinasjonen, og hver grunn forteller leseren hvorfor den siden er neste. Blokken konkurrerer ikke med artikkelen den avslutter.

Hvorfor dette elementet betyr noe

Å fullføre en nyttig side skaper et beslutningspunkt. Leseren kan forstå det umiddelbare emnet, men kan fortsatt trenge å bruke det, sammenligne alternativer, lære en forutsetning eller bevege seg mot et produkt. En relatert innhold-blokk reduserer innsatsen ved å finne det neste steget. Den tilbyr et lite sett med målrettede ruter i det øyeblikket leseren er klar til å velge, i stedet for å be dem gå tilbake til global navigasjon eller søke på nytt.

Den andre oppgaven er arkitektonisk. Intern autoritet er den viktigheten og kontekstuelle relevansen som lenker hjelper å distribuere mellom sider på samme nettsted. En lenke skaper en kant mellom to dokumenter. Plasseringen, ankerteksten og forklaringen forteller systemer for gjenfinning hva den kanten representerer: hvilken side som er den brede autoriteten, hvilken som dekker et underemne, og hvilken som svarer på et tilstøtende behov.

Maskinuttrekkbarhet betyr at et automatisert system kan gjenopprette disse relasjonene fra HTML-en uten å gjette ut fra layout. Et semantisk navigasjonsområde, en synlig overskrift, vanlige gjennomsøkbare lenker, beskrivende ankertekster og ett element per destinasjon eksponerer et rent sett med kilde–relasjon–destinasjon-uttalelser. JavaScript-avhengige karuseller, bildebaserte kort og generiske ankertekster skjuler disse uttalelsene selv når de ser polerte ut.

Begge oppgavene må overleve gjennomgang. En blokk som får klikk, men sender autoritet til urelaterte sider, skader innholdsmodellen; et korrekt klyngekart med irrelevante lenker kaster bort leserens beslutningspunkt.

Når du skal bruke det

Bruk dette elementet når siden har to til fem troverdige neste destinasjoner og relasjonen kan uttrykkes på én linje. Den hører hjemme på eviggrønt pedagogisk innhold, kommersielle forklaringssider, sammenligninger, produkt- og kategorisider, bruksområde-sider og casestudier når en annen side virkelig fremmer samme oppgave eller beslutning.

Ikke legg det til bare fordi en mal har tom plass. En side med ett enkelt formål og én nødvendig handling trenger kanskje bare sin avsluttende handlingsoppfordring. En juridisk merknad, kontoskjerm, supportsak eller kort nytte-side har kanskje ingen fornuftig redaksjonell fortsettelse. En indeks der hovedinnholdet allerede består av navigasjonskort trenger ikke en ekstra liste som gjentar dem.

Vanlige nesten-treff inkluderer:

• Et stikkord-feed svarer på «hva deler denne etiketten?», ikke «hva bør denne leseren gjøre videre?» To artikler merket «analyse» kan tjene forskjellige målgrupper og stadier.
• Nylige innlegg belønner publiseringsdato fremfor relevans. Aktualitet er nyttig for nyhetsoppdagelse, men det er ikke en relasjonsmodell.
• Populære innlegg optimaliserer for samlet trafikk, ikke for det aktuelle spørsmålet.
• Et bunntekst-sidekart støtter bred oppdagelse, ikke en liten redaksjonelt valgt sti.
• En forrige/neste-kontroll gjenspeiler publiseringsrekkefølge. Den teller bare når den rekkefølgen i seg selv er et bevisst kurs eller en sekvens.
• Innbyggede kontekstuelle lenker forklarer termer eller støtter påstander der behovet oppstår. De utfyller denne blokken, men erstatter ikke dens rolle som beslutningspunkt på slutten av siden.

Utvalg er manuelt som standard. For hver foreslått lenke noterer redaktøren en grunn som «bruker metoden», «definerer forutsetningen», «sammenligner de to alternativene som introduseres her» eller «viser bevis i praksis». Hvis grunnen bare er «samme stikkord», fjern elementet.

Automatisk utvalg er akseptabelt i nyhetsarkiver, brukergenererte samlinger eller inventarlister som er for store og volatile for element-for-element-kuratering. Selv da kreves et kontrollert kandidatsett, ekskluderinger for gjeldende URL og utløpte sider, ferskhet der tid betyr noe, relevans utover ett stikkord, en stabil tiebreaker og en redaksjonell overstyring.

Hvor du skal plassere det

Plasser blokken etter det fullførte hovedinnholdet og etter kildeblokken, men før den avsluttende handlingsoppfordringen. Grunnen er sekvensiell: kilder avslutter bevisforpliktelsen til den nåværende siden; relatert innhold tilbyr den neste lærings- eller evalueringsstien; den endelige handlingsoppfordringen tilbyr den kommersielle eller produktrelaterte stien. Når en side ikke har noen kildeblokk, følger relatert innhold etter den siste vesentlige delen.

Ikke plasser en ekstra relatert innhold-blokk andre steder på siden. Ikke sett den ved siden av duplisert forrige/neste-navigasjon, en tett stikkordssky eller en annen samling kalt «Du vil kanskje også like». Én tydelig anbefalingsregion er nok.

Anatomi

Gjengitt forklaring:

1. Seksjonsoverskrift: navngir relasjonen, for eksempel «Bruk det du har lært» eller «Sammenlign de neste alternativene». Generisk «Relatert» er akseptabelt bare når destinasjonene virkelig spenner over forskjellige handlinger.
2. Elementtittel: gir den beskrivende ankerteksten og forutsier destinasjonens primære verdi.
3. Destinasjons-URL: peker til én kanonisk, gjennomsøkbar intern URL uten en omdirigeringskjede.
4. Miniatyrbilde: skiller valgfritt en destinasjon når bilder inneholder reell identifiserende informasjon.
5. Én-linjers grunn: forklarer valgfritt hvorfor denne siden er det logiske neste steget; det anbefales sterkt når relasjonen ikke er åpenbar fra tittelen.
6. Blokkgrense: grupperer lenkene som navigasjon uten å gjøre hele kortet til et tvetydig klikkmål.

Forklaringen hører hjemme på siden heller enn inne i bildet, slik at den forblir valgbar, oversettbar og tilgjengelig for hjelpemiddelteknologi.

Designeksempler

Variantene endrer informasjonstetthet, ikke redaksjonell logikk.

Tekstbasert: standard når destinasjonstitler gjør relasjonen tydelig.

Med grunner: standard for forskjellige reisestadier. Grunnen legger til relasjonen heller enn å gjenta tittelen.

Med miniatyrbilder: reservert for tilfeller der originalbilder hjelper gjenkjenning. Bilder trenger dimensjoner og nyttig alternativ tekst, eller en tom alternativ tekst når tittelen allerede navngir destinasjonen.

Kryss-søyle: gjør relasjoner mellom innleggstyper, elementer og forretningsapplikasjoner eksplisitte. Den genereres fra gjennomgått frontmatter, ikke stikkord.

Parametre

To elementer er tillatt bare når siden har en smal, troverdig forgrening. Tre til fem er normalområdet: nok valg til å tjene forskjellige neste behov, men få nok til at hver lenke forblir synlig og bevisst. Seks er et hardt unntak for en søyle som må eksponere en komplett liten klynge. Mer enn seks blir en katalog, svekker det redaksjonelle signalet i hver kant og gjør mobilskanning kostbart.

En utelatt tittel-attributt kan hentes fra den første overskriften i element-brødteksten. Ikke oppgi begge med forskjellig tekst. En grunn kan ligge i attributtet for en enkel setning eller i brødteksten når den trenger inline-utheving; den må ikke vises to ganger.

Syntaks og kodeeksempler

Det kanoniske komponentnavnet er related-content. Den nøstede ::item{}-formen holder hver destinasjons felt samlet og forhindrer at parallelle lister kommer ut av justering.

Bærbar Markdown-direktiv

:::related-content{heading="Fortsett med playbooken" variant="reason"}
::item{title="Skriv en pålitelig veiledning" url="/seo-playbook/post-types/how-to-guide/" reason="Gjør elementreglene om til en komplett instruksjonell side."}
::item{title="Strukturer en ultimativ guide" url="/seo-playbook/post-types/ultimate-guide/" reason="Koble dette elementet til en bred søyle og dens støttende eiker."}
::item{title="Bygg en bruksområde-side" url="/seo-playbook/post-types/use-case-page/" reason="Bær pedagogisk hensikt inn i en spesifikk målgruppe og et spesifikt resultat."}
:::

Hugo-shortkode

{{< related-content heading="Fortsett med playbooken" variant="reason" >}}
  {{< item title="Skriv en pålitelig veiledning" url="/seo-playbook/post-types/how-to-guide/" reason="Gjør elementreglene om til en komplett instruksjonell side." />}}
  {{< item title="Strukturer en ultimativ guide" url="/seo-playbook/post-types/ultimate-guide/" reason="Koble dette elementet til en bred søyle og dens støttende eiker." />}}
  {{< item title="Bygg en bruksområde-side" url="/seo-playbook/post-types/use-case-page/" reason="Bær pedagogisk hensikt inn i en spesifikk målgruppe og et spesifikt resultat." />}}
{{< /related-content >}}

Dette er den bærbare målkontrakten, ikke en påstand om at dette repositoriet registrerer shortkoden. Live-eksemplet bruker semantisk HTML og legger til ingen layout-avhengighet.

WordPress-blokk eller shortkode

<!-- wp:amicited/related-content {"heading":"Fortsett med playbooken","variant":"reason"} -->
[related_item title="Skriv en pålitelig veiledning" url="/seo-playbook/post-types/how-to-guide/" reason="Gjør elementreglene om til en komplett instruksjonell side."]
[related_item title="Strukturer en ultimativ guide" url="/seo-playbook/post-types/ultimate-guide/" reason="Koble dette elementet til en bred søyle og dens støttende eiker."]
[related_item title="Bygg en bruksområde-side" url="/seo-playbook/post-types/use-case-page/" reason="Bær pedagogisk hensikt inn i en spesifikk målgruppe og et spesifikt resultat."]
<!-- /wp:amicited/related-content -->

WordPress bør bruke en registrert dynamisk blokk med nøstede elementkontroller. Shortkode-skjemaet er for systemer som ikke kan lagre nøstede blokker og må registreres før publisering.

Eksempler

Bra: hver lenke svarer på et annet neste behov

:::related-content{heading="Sett metoden ut i praksis" variant="reason"}
::item{title="Kjør QA-sjekklisten før publisering" url="/seo-playbook/process/checklists/pre-publish-qa/" reason="Verifiser lenker, bevis, tilgjengelighet og sidestruktur før lansering."}
::item{title="Bygg en veiledning" url="/seo-playbook/post-types/how-to-guide/" reason="Bruk elementet innenfor et komplett instruksjonelt format."}
::item{title="Tilpass playbooken for SaaS" url="/seo-playbook/business-types/saas/" reason="Oversett de felles reglene til en produktledet innholdsreise."}
:::

Dette fungerer fordi destinasjonene er distinkte, men forbundet: verifisering, implementering og forretningstilpasning. Ankertekstene forteller hva hver side leverer, og grunnene forklarer relasjonen til den nåværende siden.

Dårlig: stikkord-widgeten utgir seg for å være redaksjonelt utvalg

:::related-content{heading="Du vil kanskje også like"}
::item{title="Les mer" url="/blog/new-office/"}
::item{title="Klikk her" url="/features/ai-visibility/"}
::item{title="Siste innlegg" url="/blog/quarterly-roundup/"}
::item{title="SEO" url="/seo-playbook/"}
::item{title="Mer SEO" url="/blog/old-seo-notes/"}
::item{title="En annen artikkel" url="/academy/how-to-export-prompt-data/"}
::item{title="Anbefalt" url="/case-studies/hz-containers/"}
:::

Eksemplet mislykkes selv om hver URL fungerer. Sju valg overstiger området. Ankertekstene forutsier ikke destinasjonen. Destinasjonene blander selskapsnyheter, produkt, arkiv, akademi og casestudie-hensikter uten oppgitte grunner. «Siste» er en datoregel, «SEO» er for bredt, og ingenting beviser at lenkene tjener denne leserens neste oppgave.

Klyngekontrakten

En tema-klynge er en planlagt gruppe sider rundt ett emne. Søylen er den brede siden som organiserer emnet; eikene er smalere sider som svarer på deler av det. Den relaterte innhold-blokken gjør den planen om til faktiske HTML-lenker:

• Hver eike lenkes opp til søylen sin. Dette forteller leseren hvor det smale svaret hører hjemme og forhindrer at eiken blir et isolert endepunkt.
• Søylen lenker ned til hver nåværende eike. Når klyngen har mer enn seks eiker, bruk organiserte seksjoner i søyle-brødteksten heller enn å tvinge hele settet inn i én relatert innhold-blokk.
• Laterale lenker kobler en eike til en annen bare når en leser kan angi neste-steg-relasjonen. Å dele en forelder er ikke tilstrekkelig.
• Hver kant er toveis når begge retninger hjelper en leser. Den omvendte ankerteksten og grunnen kan være forskjellig fordi reisen er forskjellig.
• Fjerning, sammenslåing eller omdirigering av en side utløser en gjennomgang av hver lagrede kant som peker til den.

Innenfor denne playbooken linker en innleggstype-side til elementene den krever og til forretningstypene som tilpasser den. En elementside linker tilbake til innleggstypene som bruker den. Disse relasjonene genereres fra gjennomgått frontmatter under kryss-søyle-reglene: denne sidens postTypes-array er kilden for dens innleggstype-lenker, mens den tilsvarende innleggstype-metadaten leverer tilbakelenken. Generering håndterer gjengivelse; redaktører bestemmer fortsatt om relasjonen hører hjemme i metadata.

De bredere skrivereglene for elementer styrer hvordan metadataene forblir portable. Reparer aldri en manglende redaksjonell relasjon ved å legge til et stikkord og håpe at en widget velger riktig.

Ankertekstregler

Ankertekst er den synlige, klikkbare ordlyden i en lenke. Skriv den slik at en leser kan forutsi destinasjonen uten å lese URL-en. «Bygg en veiledning» er nyttig; «les mer», «klikk her», «lær mer» og en naken URL er det ikke.

Varier ankertekster naturlig mens du bevarer destinasjonens emne. «Lag en veiledning» og «strukturer en instruksjonell guide» fungerer; urelaterte nøkkelord-synonymer gjør det ikke. Lov aldri en mal, kalkulator, pris, studie eller sjekkliste som destinasjonen mangler.

Inne i blokken bør tittelankertekster være unike. Hvis to destinasjoner ville bruke samme tittel, legg til den skillende målgruppen, metoden eller resultatet. Hold den valgfrie grunnen utenfor ankerteksten slik at klikkmålet forblir konsist og lister for hjelpemiddelteknologi forblir nyttige.

Schema-markering og tilgjengelighet

Ingen spesiell JSON-LD-type er påkrevd. JSON-LD er et script-basert format for strukturerte data, og Schema.org er det felles vokabularet som vanligvis kodes med det. Lenkene forblir normalt en del av den omsluttende Article, TechArticle, Product eller WebPage. Ikke oppfinn en RelatedContent-skjematype.

En ItemList kan beskrive blokken bare når den virkelig er en ordnet eller navngitt redaksjonell liste og nettstedets generelle schema-policy krever det. Hvis den brukes, må itemListElement samsvare med synlig elementrekkefølge, URL-er og navn. Ikke legg til skjulte destinasjoner eller syntetiske rangeringer. En brødsmulesti er en annen relasjon og må ikke absorbere disse lenkene.

Tilgjengelighet starter med et <nav>-landemerke, det vil si en region som hjelpemiddelteknologi kan identifisere som navigasjon. Gi den en synlig overskrift koblet gjennom aria-labelledby; ARIA er settet med attributter som brukes til å eksponere grensesnittnavn og -tilstander når ren HTML alene trenger hjelp. Bruk en <ul> fordi rekkefølgen normalt ikke bærer noen rangering. Bevar synlig tastaturfokus, gjør tittelen til den primære lenken, og unngå å nøste et interaktivt kort inne i en annen lenke.

Alternativ tekst for miniatyrbilder må ikke duplisere den lenkede tittelen. Bruk tom alternativ tekst for et dekorativt miniatyrbilde. Når bildet bidrar med distinkt informasjon, beskriv kun den informasjonen. Blokken må forbli komplett med bilder eller JavaScript deaktivert, og den må ikke flytte tastaturfokus når anbefalinger oppdateres.

Skriveregler

Bruk tre til fem elementer som standard, to for en smal forgrening, og ikke mer enn seks for et dokumentert lite klyngebehov. Skriv en overskrift på to til åtte ord, tittelankertekster på tre til tolv ord, og valgfrie grunner på åtte til tjueto ord. Grunner bruker én setning, aktiv form og en konkret relasjon: bruk, sammenlign, verifiser, definer, diagnostiser eller se bevis.

Hvert element trenger en distinkt redaksjonell grunn i innholdsmodellen selv når grunnen ikke gjengis. Gå gjennom titler etter at destinasjoners overskrifter endres. Bruk kanoniske interne URL-er med ledende og avsluttende skråstreker. Fjern sporingsparametre, fragmenter som ikke identifiserer stabile seksjoner, omdirigeringer og lenker tilbake til den nåværende siden.

Plasser aldri annonser, forfatterbiografier, sosiale følg-knapper, nyhetsbrevskjemaer, stikkordsskyer, urelaterte kampanjer eller kildehenvisninger inne i dette elementet. Ikke bland ekstern lesing med interne neste steg; eksterne bevis hører hjemme i kildeblokken. Ikke bruk merker som «best», «populær» eller «anbefalt» med mindre siden definerer og støtter utvalgsbasisen.

Ton bør være hjelpsom og spesifikk, ikke presserende. Unngå «må leses», «ikke gå glipp av», kunstig knapphet og påstander om at destinasjonen er omfattende med mindre omfanget støtter det ordet. Blokken anbefaler en sti; den skaper ikke viktighet.

Innleggstyper som bruker det

Frontmatter-arrayet postTypes er sannhetskilden for følgende kryss-søyle-relasjoner.

Ikke alle kandidater trenger å gjengis på hver side. Innleggstypen definerer den kvalifiserende relasjonen; side-redaktøren velger destinasjonene som gir mening for det faktiske emnet og reisen.

QA-sjekkliste

• Blokken vises én gang, etter kilder og før den avsluttende handlingsoppfordringen.
• Siden inneholder to til fem lenker, eller en dokumentert grunn for å bruke seks.
• Hvert element har en registrert redaksjonell grunn utover et felles stikkord, kategori eller publiseringsdato.
• Hver ankertekst forutsier hva destinasjonen faktisk leverer og unngår «les mer», «klikk her» og lignende generisk språk.
• Settet støtter klyngekontrakten: eike opp, søyle ned, og lateral kun når det er virkelig relatert.
• Gjeldende URL er ekskludert, destinasjoner er kanoniske, og ingen lenke er avhengig av en omdirigering eller sporingsparameter.
• Frontmatter for relatert innhold samsvarer med de gjengitte kryss-søyle-lenkene.
• Blokken forblir lesbar, navigerbar og komplett uten miniatyrbilder eller JavaScript.
• Navigasjonsregionen har en synlig overskrift og et tilgjengelig navn; tastaturfokus er synlig.
• Miniatyrbilder eksisterer, tilfører identifiserende verdi, reserverer dimensjoner og bruker korrekt alternativ tekst.
• Grunner legger til et neste-steg-forhold i stedet for å gjenta titler.
• Kilder, annonser, skjemaer, sosiale lenker og urelaterte kampanjer forblir utenfor blokken.
• Eventuelle ItemList-strukturerte data samsvarer nøyaktig med de synlige elementene og rekkefølgen.
• Mobil-gjengivelse viser hver tittel og grunn uten en skjult horisontal karusell.

En gjennomgangsperson bør avvise bare plausible lenker. Hver enkelt må være det riktige neste steget, uttrykke en reell arkitektonisk kant og forbli tydelig i HTML.

FAQ

Academy-malen gjengir FAQ-oppføringene fra frontmatter.