Relaterade innehållsblock: Regler för internlänkning

Ett relaterat innehållsblock är en kort, manuellt vald uppsättning länkar placerad i slutet av huvudinnehållet. Det för läsaren vidare till den mest användbara nästa sidan och förmedlar intern auktoritet längs samma länk. Varje destination måste ha en redaktionell anledning att existera; gemensamma taggar ensamma räcker inte.

Det renderade exemplet är medvetet blygsamt. Dess rubrik förklarar valet, varje ankare förutspår destinationen och varje anledning berättar för läsaren varför den sidan är nästa steg. Blocket konkurrerar inte med artikeln det avslutar.

Varför detta element är viktigt

Att avsluta en användbar sida skapar en beslutspunkt. Läsaren kan förstå det omedelbara ämnet men behöver fortfarande tillämpa det, jämföra alternativ, lära sig en förkunskap eller närma sig en produkt. Ett relaterat innehållsblock minskar ansträngningen att hitta det nästa steget. Det erbjuder en liten uppsättning ändamålsenliga vägar i det ögonblick då läsaren är redo att välja, istället för att be dem återvända till global navigering eller söka igen.

Det andra jobbet är arkitektoniskt. Intern auktoritet är den betydelse och kontextuella relevans som länkar hjälper till att fördela mellan sidor på samma webbplats. En länk skapar en kant mellan två dokument. Dess position, ankare och förklaring berättar för återvinningssystem vad den kanten representerar: vilken sida som är den breda auktoriteten, vilken som täcker ett underämne och vilken som besvarar ett angränsande behov.

Maskinutvinningsbarhet innebär att ett automatiserat system kan återhämta dessa relationer från HTML-koden utan att gissa från layouten. En semantisk navigationsregion, en synlig rubrik, vanliga genomsökbara länkar, beskrivande ankare och ett objekt per destination exponerar en ren uppsättning källa–relation–destination-påståenden. JavaScript-endast-karuseller, bild-endast-kort och generiska ankare fördunklar dessa påståenden även när de ser polerade ut.

Båda jobben måste överleva granskning. Ett block som får klick men skickar auktoritet till orelaterade sidor skadar innehållsmodellen; en korrekt klusterkarta med irrelevanta länkar slösar bort läsarens beslutspunkt.

När det ska användas

Använd detta element när sidan har två till fem trovärdiga nästa destinationer och relationen kan uttryckas på en rad. Det hör hemma på evergreen-utbildningsinnehåll, kommersiella förklaringar, jämförelser, produkt- och kategorisidor, användningsfallssidor och fallstudier när en annan sida verkligen för samma uppgift eller beslut framåt.

Lägg inte till det bara för att en mall har tomt utrymme. En konverteringssida med ett enda syfte och en nödvändig åtgärd kan behöva endast sin avslutande uppmaning. Ett juridiskt meddelande, kontoskärm, supportincident eller kort verktygssida kan sakna en meningsfull redaktionell fortsättning. Ett index vars huvudinnehåll redan består av navigationskort behöver inte en andra lista som upprepar dem.

Vanliga närträffar inkluderar:

• Ett taggflöde svarar på “vad delar denna etikett?”, inte “vad ska denna läsare göra härnäst?” Två artiklar taggade “analys” kan tjäna olika målgrupper och stadier.
• Senaste inlägg belönar publiceringsdatum snarare än relevans. Aktualitet är användbart för nyhetsupptäckt, men det är ingen relationsmodell.
• Populära inlägg optimerar för aggregerad trafik, inte den aktuella frågan.
• En sidfotskarta stöder bred upptäckt, inte en liten redaktionellt vald väg.
• En föregående/nästa-kontroll speglar publiceringsordning. Den räknas endast när den ordningen i sig är en avsiktlig kurs eller sekvens.
• Inline kontextuella länkar förklarar termer eller stöder påståenden vid behovspunkten. De kompletterar detta block men ersätter inte dess beslutsroll i slutet av sidan.

Urval är manuellt som standard. För varje föreslagen länk antecknar redaktören en anledning som “tillämpar metoden”, “definierar förkunskapen”, “jämför de två alternativen som introduceras här” eller “visar bevis i praktiken”. Om anledningen bara är “samma tagg”, ta bort objektet.

Automatiskt urval är acceptabelt i nyhetsarkiv, användargenererade samlingar eller inventarier som är för stora och föränderliga för objekt-för-objekt-kurering. Även där, kräv en kontrollerad kandidatuppsättning, undantag för den aktuella webbadressen och utgångna sidor, färskhet där tid spelar roll, relevans bortom en tagg, en stabil tie-breaker och en redaktionell åsidosättningsmöjlighet.

Var det ska placeras

Placera blocket efter den fullständiga huvudinnehållskroppen och efter källblocket, men före den avslutande uppmaningen. Anledningen är sekventiell: källor avslutar bevisförpliktelsen för den aktuella sidan; relaterat innehåll erbjuder nästa inlärnings- eller utvärderingsväg; den slutliga uppmaningen erbjuder den kommersiella eller produktrelaterade vägen. När en sida inte har något källblock följer relaterat innehåll efter den sista väsentliga sektionen.

Placera inte ett andra relaterat-innehållsblock någon annanstans på sidan. Placera det inte bredvid duplicerad föregående/nästa-navigering, en tät taggmoln eller en annan samling med titeln “Du kanske även gillar”. En tydlig rekommendationsregion räcker.

Anatomi

Renderad teckenförklaring:

1. Sektionsrubrik: namnger relationen, till exempel “Tillämpa det du lärt dig” eller “Jämför nästa alternativ.” Generisk “Relaterat” är acceptabelt endast när destinationerna verkligen spänner över olika åtgärder.
2. Objektittel: tillhandahåller det beskrivande ankaret och förutspår destinationens primära värde.
3. Destinations-URL: löser upp till en kanonisk, genomsökbar intern webbadress utan omdirigeringskedja.
4. Miniatyrbild: särskiljer valfritt en destination när bildmaterial bär verklig identifierande information.
5. Enrads-anledning: förklarar valfritt varför denna sida är det logiska nästa steget; det rekommenderas starkt när relationen inte är uppenbar från titeln.
6. Blockgräns: grupperar länkarna som navigering utan att göra hela kortet till ett otydligt klickmål.

Teckenförklaringen hör hemma på sidan snarare än inuti bilden så att den förblir valbar, översättningsbar och tillgänglig för hjälpmedelsteknik.

Designexempel

Varianterna ändrar informationsdensitet, inte redaktionell logik.

Endast text: standard när destinationsrubriker gör relationen tydlig.

Med anledningar: standard för olika resstadier. Anledningen lägger till relationen snarare än att upprepa titeln.

Med miniatyrbilder: reserverat för fall där originalbilder hjälper till med igenkänning. Bilder behöver dimensioner och användbar alternativ text, eller en tom alternativtext när titeln redan namnger destinationen.

Tväpelare: gör relationer mellan inläggstyper, element och affärstillämpningar tydliga. Det genereras från granskad frontmatter, inte taggar.

Parametrar

Två objekt är endast tillåtna när sidan har en smal, trovärdig vägförgrening. Tre till fem är det normala spannet: tillräckligt med val för att tjäna olika nästa behov, men tillräckligt få för att varje länk ska förbli synlig och avsiktlig. Sex är ett hårt undantag för en pelare som måste exponera ett komplett litet kluster. Fler än sex blir en katalog, försvagar den redaktionella signalen för varje kant och gör mobilskanning dyr.

Ett utelämnat titelattribut kan härledas från den första rubriken i objektets brödtext. Ange inte båda med olika text. En anledning kan finnas i attributet för en enkel mening eller i brödtexten när den behöver inline-betoning; den får inte förekomma två gånger.

Syntax och kodexempel

Det kanoniska komponentnamnet är related-content. Den nästlade ::item{}-formen håller varje destinations fält samman och förhindrar att parallella arrayer glider ur linje.

Portabel Markdown-direktiv

:::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."}
:::

Hugo shortcode

{{< 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 >}}

Detta är det portabla målkontraktet, inte ett påstående att detta arkiv registrerar shortcoden. Det levande exemplet använder semantisk HTML och lägger till inget layoutberoende.

WordPress-block eller shortcode

<!-- 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 bör använda ett registrerat dynamiskt block med nästlade objektkontroller. Shortcode-formen är för system som inte kan lagra nästlade block och måste registreras före publicering.

Exempel

Bra: varje länk besvarar ett annat nästa behov

:::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."}
:::

Detta fungerar eftersom destinationerna är distinkta men sammankopplade: verifiering, implementering och affärsanpassning. Ankarna anger vad varje sida levererar, och anledningarna förklarar relationen till den aktuella sidan.

Dåligt: taggwidgeten utger sig för att vara redaktionellt urval

:::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/"}
:::

Exemplet misslyckas även om varje webbadress löser upp sig. Sju val överstiger spannet. Ankarna förutspår inte destinationen. Destinationerna blandar företagsnyheter, produkt, arkiv, academy och fallstudieintention utan angivna anledningar. “Senaste” är en datumsregel, “SEO” är alldeles för brett och inget bevisar att länkarna tjänar denna läsares nästa uppgift.

Klusterkontraktet

Ett ämneskluster är en planerad grupp sidor kring ett ämne. Dess pelare är den breda sidan som organiserar ämnet; dess ekrar är smalare sidor som besvarar delar av det. Det relaterade innehållsblocket omvandlar den planen till faktiska HTML-länkar:

• Varje eker länkar upp till sin pelare. Detta berättar för läsare var det smala svaret hör hemma och förhindrar att ekern blir en isolerad slutpunkt.
• Pelaren länkar ner till varje aktuell eker. När klustret har fler än sex ekrar, använd organiserade sektioner i pelarens brödtext istället för att tvinga in hela uppsättningen i ett relaterat innehållsblock.
• Laterala länkar kopplar en eker till en annan endast när en läsare kan ange nästa-steg-relationen. Att dela en förälder är inte tillräckligt.
• Varje kant är dubbelriktad när båda riktningarna hjälper en läsare. Det omvända ankaret och anledningen kan skilja sig eftersom resan skiljer sig.
• Borttagning, sammanslagning eller omdirigering av en sida utlöser en granskning av varje lagrad kant som pekar på den.

Inom denna playbook länkar en inläggstypsida till de element den kräver och till de affärstyper som anpassar den. En elementsida länkar tillbaka till de inläggstyper som använder den. Dessa relationer genereras från granskad frontmatter enligt tväpelarreglerna: denna sidas postTypes-array är källan för dess inläggstypslänkar, medan motsvarande inläggstypsmetadata tillhandahåller returkanten. Generering hanterar rendering; redaktörer bestämmer fortfarande om relationen hör hemma i metadata.

De bredare skrivreglerna för element styr hur den metadatan förblir portabel. Reparera aldrig en saknad redaktionell relation genom att lägga till en tagg och hoppas att en widget väljer korrekt.

Regler för ankartext

Ankartext är den synliga, klickbara formuleringen av en länk. Skriv den så att en läsare kan förutspå destinationen utan att läsa webbadressen. “Skapa en how-to-guide” är användbart; “läs mer”, “klicka här”, “lär dig mer” och en naken webbadress är det inte.

Variera ankare naturligt samtidigt som destinationens ämne bevaras. “Skapa en how-to-guide” och “strukturera en instruktionsguide” fungerar; orelaterade nyckelordssynonymer gör det inte. Lova aldrig en mall, kalkylator, pris, studie eller checklista som destinationen saknar.

Inuti blocket bör titelankare vara unika. Om två destinationer skulle använda samma titel, lägg till den särskiljande målgruppen, metoden eller resultatet. Håll den valfria anledningen utanför ankaret så att klickmålet förblir koncist och hjälpmedelsteknikens länklistor förblir användbara.

Schema-markup och tillgänglighet

Ingen särskild JSON-LD-typ krävs. JSON-LD är ett skriptbaserat format för strukturerad data, och Schema.org är den gemensamma vokabulär som vanligtvis kodas med det. Länkarna förblir normalt en del av den omslutande Article, TechArticle, Product eller WebPage. Hitta inte på en RelatedContent-schemtyp.

En ItemList kan beskriva blocket endast när det verkligen är en ordnad eller namngiven redaktionell lista och webbplatsövergripande schemapolicy kräver det. Om den används måste itemListElement matcha den synliga objektordningen, webbadresserna och namnen. Lägg inte till dolda destinationer eller syntetiska betyg. En brödsmula är en annan relation och får inte absorbera dessa länkar.

Tillgänglighet börjar med ett <nav>-landmärke, vilket innebär en region som hjälpmedelsteknik kan identifiera som navigering. Ge den en synlig rubrik som är kopplad genom aria-labelledby; ARIA är uppsättningen attribut som används för att exponera gränssnittsnamn och tillstånd när inbyggd HTML ensam behöver hjälp. Använd en <ul> eftersom ordningen normalt inte bär någon rangordning. Bevara synligt tangentbordsfokus, gör titeln till den primära länken och undvik att placera ett interaktivt kort inuti en annan länk.

Alternativ text för miniatyrbilder får inte duplicera den länkade titeln. Använd tom alternativ text för en dekorativ miniatyrbild. När bilden bidrar med distinkt information, beskriv endast den informationen. Blocket måste förbli komplett med bilder eller JavaScript inaktiverat, och det får inte flytta tangentbordsfokus när rekommendationer uppdateras.

Skrivregler

Använd tre till fem objekt som standard, två för en smal vägförgrening och högst sex för ett dokumenterat litet klusterbehov. Skriv en rubrik på två till åtta ord, titelankare på tre till tolv ord och valfria anledningar på åtta till tjugotvå ord. Anledningar använder en mening, aktiv form och en konkret relation: tillämpa, jämför, verifiera, definiera, diagnostisera eller se bevis.

Varje objekt behöver en distinkt redaktionell anledning i innehållsmodellen även när anledningen inte renderas. Granska titlar efter att destinationsrubriker ändrats. Använd kanoniska interna webbadresser med inledande och avslutande snedstreck. Ta bort spårningsparametrar, fragment som inte identifierar stabila sektioner, omdirigeringar och länkar tillbaka till den aktuella sidan.

Placera aldrig annonser, författarbiografier, sociala följknappar, nyhetsbrevsformulär, taggmoln, orelaterade kampanjer eller källhänvisningar inuti detta element. Blanda inte extern läsning med interna nästa steg; externa bevis hör hemma i källblocket. Använd inte märkningar som “bäst”, “populär” eller “rekommenderad” om inte sidan definierar och stöder urvalsgrunden.

Ton bör vara hjälpsam och specifik, inte brådskande. Undvik “måste läsas”, “missa inte”, artificiell brist och påståenden om att destinationen är heltäckande om inte dess omfattning stöder det ordet. Blocket rekommenderar en väg; det skapar inte betydelse.

Inläggstyper som använder det

Frontmatter-arrayen postTypes är sanningskällan för följande tväpelarrelationer.

Inte varje kandidat behöver renderas på varje sida. Inläggstypen definierar den kvalificerade relationen; sidredaktören väljer de destinationer som är meningsfulla för det faktiska ämnet och resan.

QA-checklista

• Blocket visas en gång, efter källor och före den avslutande uppmaningen.
• Sidan innehåller två till fem länkar, eller en dokumenterad anledning till att använda sex.
• Varje objekt har en registrerad redaktionell anledning utöver en delad tagg, kategori eller publiceringsdatum.
• Varje ankare förutspår vad destinationen faktiskt levererar och undviker “läs mer”, “klicka här” och liknande generiskt språk.
• Uppsättningen stöder klusterkontraktet: eker upp, pelare ner och lateral endast när verkligt relaterad.
• Den aktuella webbadressen är utesluten, destinationer är kanoniska och ingen länk förlitar sig på en omdirigering eller spårningsparameter.
• Relaterat-innehåll-frontmattern överensstämmer med de renderade tväpelarlänkarna.
• Blocket förblir läsbart, navigerbart och komplett utan miniatyrbilder eller JavaScript.
• Navigationsregionen har en synlig rubrik och ett tillgängligt namn; tangentbordsfokus är synligt.
• Miniatyrbilder finns, tillför identifierande värde, reserverar dimensioner och använder korrekt alternativ text.
• Anledningar lägger till ett nästa-steg-förhållande istället för att upprepa titlar.
• Källor, annonser, formulär, sociala länkar och orelaterade kampanjer förblir utanför blocket.
• Eventuell ItemList-strukturerad data matchar exakt de synliga objekten och ordningen.
• Mobilrendering exponerar varje titel och anledning utan en dold horisontell karusell.

En granskare bör avvisa enbart troliga länkar. Varje enskild måste vara rätt nästa steg, uttrycka en verklig arkitektonisk kant och förbli tydlig i HTML.

FAQ

Academy-mallen renderar FAQ-posterna från frontmatter.