Relateret indholdsblokke: Regler for intern linking

En relateret indholdsblok er et kort, manuelt udvalgt sæt links placeret i slutningen af hovedindholdet. Den fører en læser til den mest nyttige næste side og fører intern autoritet ad samme link. Hver destination skal have en redaktionel grund til at eksistere; fælles tags alene er ikke nok.

Det gengivne eksempel er bevidst beskedent. Dets overskrift forklarer valget, hvert anker forudsiger destinationen, og hver grund fortæller læseren, hvorfor den side er næste skridt. Blokken konkurrerer ikke med den artikel, den afslutter.

Hvorfor dette element er vigtigt

Det at afslutte en nyttig side skaber et beslutningspunkt. Læseren forstår måske det umiddelbare emne, men har stadig brug for at anvende det, sammenligne muligheder, lære en forudsætning eller bevæge sig mod et produkt. En relateret indholdsblok reducerer indsatsen for at finde det næste skridt. Den tilbyder et lille sæt af formålstjenlige ruter i det øjeblik, hvor læseren er klar til at vælge, i stedet for at bede dem om at vende tilbage til global navigation eller søge igen.

Det andet formål er arkitektonisk. Intern autoritet er den betydning og kontekstuelle relevans, som links hjælper med at distribuere mellem sider på samme websted. Et link skaber en kant mellem to dokumenter. Dets position, anker og forklaring fortæller genfindingssystemer, hvad den kant repræsenterer: hvilken side er den brede autoritet, hvilken dækker et underemne, og hvilken besvarer et tilstødende behov.

Maskinel udtrækkelighed betyder, at et automatiseret system kan genfinde disse relationer fra HTML uden at gætte ud fra layout. En semantisk navigationsregion, en synlig overskrift, almindelige gennemsøgbare links, beskrivende ankere og ét element pr. destination eksponerer et rent sæt af kilde–relation–destination-udsagn. JavaScript-only-karruseller, billede-only-kort og generiske ankere skjuler disse udsagn, selv når de ser polerede ud.

Begge opgaver skal overleve gennemgang. En blok, der får klik, men sender autoritet til urelaterede sider, skader indholdsmodellen; et korrekt klyngekort med irrelevante links spilder læserens beslutningspunkt.

Hvornår skal det bruges

Brug dette element, når siden har to til fem troværdige næste destinationer, og relationen kan angives på én linje. Det hører hjemme på eviggrønt uddannelsesindhold, kommercielle forklaringer, sammenligninger, produkt- og kategorisider, brugssituation-sider og casestudier, når en anden side reelt fremmer den samme opgave eller beslutning.

Tilføj det ikke blot, fordi en skabelon har tom plads. En enkeltformåls-konverteringsside med én nødvendig handling har måske kun brug for sit afsluttende call to action. En juridisk meddelelse, kontoskærm, supportsag eller kort hjælpeside har muligvis ingen fornuftig redaktionel fortsættelse. Et indeks, hvis hovedindhold allerede består af navigationskort, behøver ikke en anden liste, der gentager dem.

Almindelige næsten-missere inkluderer:

• Et tag-feed besvarer “hvad deler denne etiket?”, ikke “hvad skal denne læser gøre herefter?” To artikler tagget “analyse” kan betjene forskellige målgrupper og stadier.
• Seneste indlæg belønner offentliggørelsesdato frem for relevans. Nyhed er nyttigt til nyhedsopdagelse, men det er ikke en relationsmodel.
• Populære indlæg optimerer for samlet trafik, ikke det aktuelle spørgsmål.
• Et footersitemap understøtter bred opdagelse, ikke en lille redaktionelt valgt sti.
• En forrige/næste-kontrol afspejler publiceringsrækkefølge. Den tæller kun, når den rækkefølge i sig selv er et bevidst forløb eller sekvens.
• Indlejrede kontekstuelle links forklarer udtryk eller understøtter påstande på behovsstedet. De supplerer denne blok, men erstatter ikke dens beslutningsrolle ved sidens afslutning.

Udvælgelse er som standard manuel. For hvert foreslået link registrerer redaktøren en grund som “anvender metoden”, “definerer forudsætningen”, “sammenligner de to muligheder, der introduceres her” eller “viser dokumentation i praksis.” Hvis grunden blot er “samme tag”, skal elementet fjernes.

Automatisk udvælgelse er acceptabelt i nyhedsarkiver, brugergenererede samlinger eller inventarer, der er for store og volatile til emne-for-emne-kuratering. Selv der kræves et kontrolleret kandidatsæt, udeladelser for den aktuelle URL og udløbne sider, friskhed hvor tid betyder noget, relevans ud over ét tag, en stabil tie-breaker og en redaktionel overstyring.

Hvor skal den placeres

Placer blokken efter det komplette hovedindhold og efter kildeblokken, men før det afsluttende call to action. Begrundelsen er sekventiel: kilder afslutter dokumentationsforpligtelsen for den aktuelle side; relateret indhold tilbyder den næste lærings- eller evalueringssti; det afsluttende call to action tilbyder den kommercielle eller produktmæssige sti. Når en side ikke har nogen kildeblok, følger relateret indhold efter det sidste væsentlige afsnit.

Placer ikke en anden relateret indholdsblok andetsteds på siden. Placer den ikke ved siden af duplikeret forrige/næste-navigation, en tæt tagsky eller en anden samling med titlen “Du kunne også lide.” Én tydelig anbefalingsregion er nok.

Anatomi

Gengivet forklaring:

1. Afsnitsoverskrift: navngiver relationen, f.eks. “Anvend det, du har lært” eller “Sammenlign de næste muligheder.” Generisk “Relateret” er kun acceptabelt, når destinationerne reelt spænder over forskellige handlinger.
2. Elementtitel: leverer det beskrivende anker og forudsiger destinationens primære værdi.
3. Destinations-URL: opløses til én kanonisk, gennemsøgbar intern URL uden en omdirigeringskæde.
4. Miniaturebillede: skelner eventuelt en destination, når billedsprog bærer reel identifikationsinformation.
5. Énliniers begrundelse: forklarer eventuelt, hvorfor denne side er det logiske næste skridt; det anbefales stærkt, når relationen ikke er indlysende ud fra titlen.
6. Blokafgrænsning: grupperer linkene som navigation uden at gøre hele kortet til et tvetydigt klikmål.

Forklaringen hører til på siden frem for inde i billedet, så den forbliver valgbar, oversættelig og tilgængelig for hjælpeteknologi.

Designeksempler

Varianterne ændrer informationstæthed, ikke redaktionel logik.

Kun tekst: standarden, når destinationstitler gør relationen tydelig.

Med begrundelser: standarden for forskellige rejsetrin. Begrundelsen tilføjer relationen i stedet for at gentage titlen.

Med miniaturebilleder: forbeholdt tilfælde, hvor originalt billedsprog hjælper genkendelse. Billeder har brug for dimensioner og nyttig alternativ tekst eller en tom alternativ tekst, når titlen allerede navngiver destinationen.

Kryds-søjle: gør relationer mellem post-typer, elementer og forretningsapplikationer eksplicitte. Den genereres fra gennemgået frontmatter, ikke tags.

Parametre

To elementer er kun tilladt, når siden har en snæver, troværdig forgrening. Tre til fem er det normale bånd: nok valg til at betjene forskellige næste behov, men få nok til, at hvert link forbliver synligt og bevidst. Seks er en hård undtagelse for en søjle, der skal eksponere en komplet lille klynge. Mere end seks bliver en mappe, svækker det redaktionelle signal for hver kant og gør mobilskanning dyr.

En udeladt titelattribut kan udledes fra den første overskrift i elementbrødteksten. Angiv ikke begge med forskellig tekst. En begrundelse kan leve i attributten for en simpel sætning eller i brødteksten, når den har brug for indlejret fremhævning; den må ikke optræde to gange.

Syntaks og kodeeksempler

Det kanoniske komponentnavn er related-content. Den indlejrede ::item{}-form holder hver destinations felter samlet og forhindrer parallelle arrays i at glide ud af justering.

Bærbar Markdown-direktiv

:::related-content{heading="Fortsæt med playbooken" variant="reason"}
::item{title="Skriv en pålidelig vejledning" url="/seo-playbook/post-types/how-to-guide/" reason="Omdan elementreglerne til en komplet instruktionsside."}
::item{title="Strukturer en ultimativ guide" url="/seo-playbook/post-types/ultimate-guide/" reason="Forbind dette element til en bred søjle og dens understøttende eger."}
::item{title="Opbyg en brugssituation-side" url="/seo-playbook/post-types/use-case-page/" reason="Før uddannelsesmæssig hensigt ind i en bestemt målgruppe og et bestemt resultat."}
:::

Hugo shortcode

{{< related-content heading="Fortsæt med playbooken" variant="reason" >}}
  {{< item title="Skriv en pålidelig vejledning" url="/seo-playbook/post-types/how-to-guide/" reason="Omdan elementreglerne til en komplet instruktionsside." />}}
  {{< item title="Strukturer en ultimativ guide" url="/seo-playbook/post-types/ultimate-guide/" reason="Forbind dette element til en bred søjle og dens understøttende eger." />}}
  {{< item title="Opbyg en brugssituation-side" url="/seo-playbook/post-types/use-case-page/" reason="Før uddannelsesmæssig hensigt ind i en bestemt målgruppe og et bestemt resultat." />}}
{{< /related-content >}}

Dette er den bærbare målkontrakt, ikke en påstand om, at dette register registrerer shortcode’en. Live-eksemplet bruger semantisk HTML og tilføjer ingen layoutafhængighed.

WordPress-blok eller shortcode

<!-- wp:amicited/related-content {"heading":"Fortsæt med playbooken","variant":"reason"} -->
[related_item title="Skriv en pålidelig vejledning" url="/seo-playbook/post-types/how-to-guide/" reason="Omdan elementreglerne til en komplet instruktionsside."]
[related_item title="Strukturer en ultimativ guide" url="/seo-playbook/post-types/ultimate-guide/" reason="Forbind dette element til en bred søjle og dens understøttende eger."]
[related_item title="Opbyg en brugssituation-side" url="/seo-playbook/post-types/use-case-page/" reason="Før uddannelsesmæssig hensigt ind i en bestemt målgruppe og et bestemt resultat."]
<!-- /wp:amicited/related-content -->

WordPress bør bruge en registreret dynamisk blok med indlejrede elementkontroller. Shortcode-formen er til systemer, der ikke kan gemme indlejrede blokke, og skal registreres før offentliggørelse.

Eksempler

Godt: hvert link besvarer et forskelligt næste behov

:::related-content{heading="Sæt metoden i praksis" variant="reason"}
::item{title="Kør den præ-publicerings QA-tjekliste" url="/seo-playbook/process/checklists/pre-publish-qa/" reason="Verificer links, dokumentation, tilgængelighed og sidestruktur før udgivelse."}
::item{title="Opbyg en vejledning" url="/seo-playbook/post-types/how-to-guide/" reason="Anvend elementet inden for et komplet instruktionsformat."}
::item{title="Tilpas playbooken til SaaS" url="/seo-playbook/business-types/saas/" reason="Oversæt de fælles regler til en produktledet indholdsrejse."}
:::

Dette virker, fordi destinationerne er forskellige, men forbundne: verifikation, implementering og forretningstilpasning. Ankerne angiver, hvad hver side leverer, og begrundelserne forklarer relationen til den aktuelle side.

Dårligt: tag-widget’en udgiver sig for at være redaktionel udvælgelse

:::related-content{heading="Du kunne også lide"}
::item{title="Læs mere" url="/blog/new-office/"}
::item{title="Klik her" url="/features/ai-visibility/"}
::item{title="Seneste indlæg" url="/blog/quarterly-roundup/"}
::item{title="SEO" url="/seo-playbook/"}
::item{title="Mere SEO" url="/blog/old-seo-notes/"}
::item{title="En anden artikel" url="/academy/how-to-export-prompt-data/"}
::item{title="Anbefalet" url="/case-studies/hz-containers/"}
:::

Eksemplet fejler, selvom hver URL opløses. Syv valg overskrider båndet. Ankerne forudsiger ikke destinationen. Destinationerne blander virksomhedsnyheder, produkt, arkiv, akademi og casestudie-hensigt uden angivne begrundelser. “Seneste” er en datoregel, “SEO” er for bredt, og intet beviser, at linkene tjener denne læsers næste opgave.

Klyngekontrakten

En emneklynge er en planlagt gruppe af sider om ét emne. Dens søjle er den brede side, der organiserer emnet; dens eger er smallere sider, der besvarer dele af det. Den relaterede indholdsblok omsætter denne plan til faktiske HTML-links:

• Hver eger linker op til sin søjle. Dette fortæller læserne, hvor det snævre svar hører til, og forhindrer egeren i at blive et isoleret slutpunkt.
• Søjlen linker ned til hver aktuel eger. Når klyngen har mere end seks eger, brug organiserede sektioner i søjlebrødteksten i stedet for at tvinge det komplette sæt ind i én relateret indholdsblok.
• Laterale links forbinder én eger til en anden, kun når en læser kan angive næste-skridt-relationen. At dele en forælder er ikke tilstrækkeligt.
• Hver kant er tovejs, når begge retninger hjælper en læser. Det omvendte anker og den omvendte begrundelse kan være forskellige, fordi rejsen er forskellig.
• Sletning, sammenlægning eller omdirigering af en side udløser en gennemgang af hver gemt kant, der peger på den.

Inden for denne playbook linker en post-type-side til de elementer, den kræver, og til de forretningstyper, der tilpasser den. En elementside linker tilbage til de post-typer, der bruger den. Disse relationer genereres fra gennemgået frontmatter under kryds-søjle-reglerne: denne sides postTypes-array er kilden til dens post-type-links, mens den tilsvarende post-type-metadata leverer returkanten. Generering håndterer gengivelse; redaktører beslutter stadig, om relationen hører hjemme i metadata.

De bredere regler for skrivning af elementer styrer, hvordan disse metadata forbliver portable. Reparer aldrig en manglende redaktionel relation ved at tilføje et tag og håbe, at en widget vælger korrekt.

Regler for ankertekst

Ankertekst er den synlige, klikkbare formulering af et link. Skriv den, så en læser kan forudsige destinationen uden at læse URL’en. “Opbyg en vejledning” er nyttigt; “læs mere,” “klik her,” “lær mere” og en nøgen URL er ikke.

Variér ankere naturligt, mens du bevarer destinationens emne. “Opret en vejledning” og “strukturer en instruktionsguide” virker; urelaterede keywordsynonymer gør ikke. Lov aldrig en skabelon, lommeregner, pris, undersøgelse eller tjekliste, som destinationen mangler.

Inde i blokken skal titelankere være unikke. Hvis to destinationer ville bruge samme titel, tilføj den skelne målgruppe, metode eller resultat. Hold den valgfrie begrundelse uden for ankeret, så klikmålet forbliver kortfattet, og linklister til hjælpeteknologi forbliver nyttige.

Schema-markup og tilgængelighed

Der kræves ingen særlig JSON-LD-type. JSON-LD er et script-baseret format til struktureret data, og Schema.org er det fælles vokabular, der ofte kodes med det. Linkene forbliver normalt en del af den omsluttende Article, TechArticle, Product eller WebPage. Opfind ikke en RelatedContent-schematype.

En ItemList kan beskrive blokken, kun når den reelt er en ordnet eller navngivet redaktionel liste, og site-dækkende schemapolitik kræver det. Hvis den bruges, skal itemListElement matche den synlige elementrækkefølge, URL’er og navne. Tilføj ikke skjulte destinationer eller syntetiske bedømmelser. En brødkrummesti er en anden relation og må ikke absorbere disse links.

Tilgængelighed starter med et <nav>-landmark, altså en region som hjælpeteknologi kan identificere som navigation. Giv den en synlig overskrift forbundet via aria-labelledby; ARIA er det sæt af attributter, der bruges til at eksponere grænsefladenavne og -tilstande, når native HTML alene har brug for hjælp. Brug en <ul>, fordi rækkefølgen normalt ikke bærer nogen rangering. Bevar synligt tastaturfokus, gør titlen til det primære link, og undgå at indlejre et interaktivt kort inde i et andet link.

Alternativ tekst til miniaturebilleder må ikke duplikere den linkede titel. Brug tom alternativ tekst til et dekorativt miniaturebillede. Når billedet bidrager med særskilt information, beskriv kun den information. Blokken skal forblive komplet med billeder eller JavaScript deaktiveret, og den må ikke flytte tastaturfokus, når anbefalinger opdateres.

Skriveregler

Brug som standard tre til fem elementer, to til en snæver forgrening, og ikke mere end seks til et dokumenteret lille-klynge-behov. Skriv en overskrift på to til otte ord, titelankere på tre til tolv ord og valgfrie begrundelser på otte til toogtyve ord. Begrundelser bruger én sætning, aktiv form og en konkret relation: anvend, sammenlign, verificer, definer, diagnosticer eller se dokumentation.

Hvert element har brug for en særskilt redaktionel grund i indholdsmodellen, selv når begrundelsen ikke gengives. Gennemgå titler, efter destinationsoverskrifter ændrer sig. Brug kanoniske interne URL’er med indledende og afsluttende skråstreger. Fjern sporingsparametre, fragmenter der ikke identificerer stabile sektioner, omdirigeringer og links tilbage til den aktuelle side.

Placer aldrig reklamer, forfatterbiografier, sociale følg-knapper, nyhedsbrevsformularer, tagskyer, urelaterede kampagner eller kildehenvisninger inde i dette element. Bland ikke ekstern læsning med interne næste skridt; ekstern dokumentation hører til i kildeblokken. Brug ikke badges som “bedst,” “populær” eller “anbefalet,” medmindre siden definerer og understøtter udvælgelsesgrundlaget.

Tonene bør være hjælpsom og specifik, ikke presserende. Undgå “skal læses,” “gå ikke glip af,” kunstig knaphed og påstande om, at destinationen er omfattende, medmindre dens omfang understøtter det ord. Blokken anbefaler en sti; den fremstiller ikke betydning.

Post-typer, der bruger det

Frontmatterens postTypes-array er sandhedskilden for følgende kryds-søjle-relationer.

Ikke hver kandidat behøver at blive gengivet på hver side. Post-typen definerer den berettigede relation; sidedaktøren vælger de destinationer, der giver mening for det aktuelle emne og rejse.

QA-tjekliste

• Blokken vises én gang, efter kilder og før det afsluttende call to action.
• Siden indeholder to til fem links eller en dokumenteret grund til at bruge seks.
• Hvert element har en registreret redaktionel grund ud over et fælles tag, kategori eller offentliggørelsesdato.
• Hvert anker forudsiger, hvad destinationen rent faktisk leverer, og undgår “læs mere,” “klik her” og lignende generisk sprog.
• Sættet understøtter klyngekontrakten: eger op, søjle ned og lateral kun når reelt relateret.
• Den aktuelle URL er udeladt, destinationer er kanoniske, og intet link afhænger af en omdirigering eller sporingsparameter.
• Frontmatteren for relateret indhold stemmer overens med de gengivne kryds-søjle-links.
• Blokken forbliver læsbar, navigerbar og komplet uden miniaturebilleder eller JavaScript.
• Navigationsregionen har en synlig overskrift og et tilgængeligt navn; tastaturfokus er synligt.
• Miniaturebilleder findes, tilføjer identifikationsværdi, reserverer dimensioner og bruger korrekt alternativ tekst.
• Begrundelser tilføjer et næste-skridt-forhold i stedet for at gentage titler.
• Kilder, annoncer, formularer, sociale links og urelaterede kampagner forbliver uden for blokken.
• Eventuelt ItemList-struktureret data matcher nøjagtigt de synlige elementer og rækkefølge.
• Mobilgengivelse eksponerer hver titel og begrundelse uden en skjult horisontal karrusel.

En gennemganger bør afvise kun plausible links. Hvert enkelt skal være det rigtige næste skridt, udtrykke en reel arkitektonisk kant og forblive tydeligt i HTML.

FAQ

Akademiskabelonen gengiver FAQ-posterne fra frontmatter.