Related Content Blocks: Internal Linking Rules

A related content block is a short, manually selected set of links placed at the end of the main body. It carries a reader to the most useful next page and carries internal authority along the same link. Each destination must have an editorial reason to exist; shared tags alone are not enough.

The rendered example is deliberately modest. Its heading explains the choice, every anchor predicts the destination, and every reason tells the reader why that page is next. The block does not compete with the article it concludes.

Why this element matters

Finishing a useful page creates a decision point. The reader may understand the immediate subject yet still need to apply it, compare options, learn a prerequisite, or move toward a product. A related content block reduces the effort of finding that next step. It offers a small set of purposeful routes at the moment when the reader is ready to choose, rather than asking them to return to global navigation or search again.

The second job is architectural. Internal authority is the importance and contextual relevance that links help distribute among pages on the same site. A link creates an edge between two documents. Its position, anchor, and explanation tell retrieval systems what that edge represents: which page is the broad authority, which covers a subtopic, and which answers an adjacent need.

Machine extractability means an automated system can recover those relationships from the HTML without guessing from layout. A semantic navigation region, a visible heading, ordinary crawlable links, descriptive anchors, and one item per destination expose a clean set of source–relationship–destination statements. JavaScript-only carousels, image-only cards, and generic anchors obscure those statements even when they look polished.

Both jobs must survive review. A block that earns clicks but sends authority to unrelated pages damages the content model; a correct cluster map with irrelevant links wastes the reader’s decision point.

When to use it

Use this element when the page has two to five credible next destinations and the relationship can be stated in one line. It belongs on evergreen educational content, commercial explainers, comparisons, product and category pages, use-case pages, and case studies when another page genuinely advances the same task or decision.

Do not add it simply because a template has empty space. A single-purpose conversion page with one necessary action may need only its closing call to action. A legal notice, account screen, support incident, or short utility page may have no sensible editorial continuation. An index whose main body already consists of navigational cards does not need a second list repeating them.

Common near misses include:

• A tag feed answers “what shares this label?”, not “what should this reader do next?” Two articles tagged “analytics” may serve different audiences and stages.
• Recent posts reward publication date rather than relevance. Recency is useful for news discovery, but it is not a relationship model.
• Popular posts optimize for aggregate traffic, not the current question.
• A footer sitemap supports broad discovery, not a small editorially chosen path.
• A previous/next control reflects publishing order. It counts only when that order is itself a deliberate course or sequence.
• Inline contextual links explain terms or support claims at the point of need. They complement this block but do not replace its end-of-page decision role.

Selection is manual by default. For every proposed link, the editor records a reason such as “applies the method,” “defines the prerequisite,” “compares the two options introduced here,” or “shows evidence in practice.” If the reason is merely “same tag,” remove the item.

Automatic selection is acceptable in news archives, user-generated collections, or inventories too large and volatile for item-by-item curation. Even there, require a controlled candidate set, exclusions for the current URL and expired pages, freshness where time matters, relevance beyond one tag, a stable tie-breaker, and an editorial override.

Ready to Monitor Your AI Visibility?

Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.

Get Started Contact

Where to place it

Place the block after the complete main body and after the sources block, but before the closing call to action. The reason is sequential: sources close the evidence obligation of the current page; related content offers the next learning or evaluation path; the final call to action offers the commercial or product path. When a page has no sources block, related content follows the final substantive section.

Do not place a second related-content block elsewhere on the page. Do not sit it beside duplicated previous/next navigation, a dense tag cloud, or another collection titled “You may also like.” One clear recommendation region is enough.

Anatomy

Rendered legend:

1. Section heading: names the relationship, such as “Apply what you learned” or “Compare the next options.” Generic “Related” is acceptable only when the destinations genuinely span different actions.
2. Item title: supplies the descriptive anchor and predicts the destination’s primary value.
3. Destination URL: resolves to one canonical, crawlable internal URL without a redirect chain.
4. Thumbnail: optionally distinguishes a destination when imagery carries real identifying information.
5. One-line reason: optionally explains why this page is the logical next step; it is strongly recommended when the relationship is not obvious from the title.
6. Block boundary: groups the links as navigation without making the entire card an ambiguous click target.

The legend belongs in the page rather than inside the image so it remains selectable, translatable, and available to assistive technology.

Stay Updated on AI Visibility Trends

Get the latest insights on AI mentions, brand monitoring, and optimization strategies.

Email address

Subscribe

Design examples

The variants change information density, not editorial logic.

Text-only: the default when destination titles make the relationship clear.

With reasons: the default for different journey stages. The reason adds the relationship rather than restating the title.

With thumbnails: reserved for cases where original imagery helps recognition. Images need dimensions and useful alternative text, or an empty alternative when the title already names the destination.

Cross-pillar: makes relationships between post types, elements, and business applications explicit. It is generated from reviewed frontmatter, not tags.

Parameters

Two items are allowed only when the page has a narrow, credible fork. Three to five is the normal band: enough choice to serve different next needs, but few enough for each link to remain visible and intentional. Six is a hard exception for a pillar that must expose a complete small cluster. More than six becomes a directory, weakens the editorial signal of each edge, and makes mobile scanning expensive.

An omitted title attribute may be derived from the first heading in the item body. Do not provide both with different text. A reason may live in the attribute for a simple sentence or in the body when it needs inline emphasis; it must not appear twice.

Syntax and code examples

The canonical component name is related-content. The nested ::item{} form keeps each destination’s fields together and prevents parallel arrays from drifting out of alignment.

Portable Markdown directive

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

This is the portable target contract, not a claim that this repository registers the shortcode. The live example uses semantic HTML and adds no layout dependency.

WordPress block or 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 should use a registered dynamic block with nested item controls. The shortcode form is for systems that cannot store nested blocks and must be registered before publication.

Examples

Good: each link answers a different next need

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

This works because the destinations are distinct but connected: verification, implementation, and business adaptation. The anchors state what each page delivers, and the reasons explain the relationship to the current page.

Bad: the tag widget masquerades as editorial selection

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

The example fails even if every URL resolves. Seven choices exceed the band. The anchors do not predict the destination. The destinations mix company news, product, archive, academy, and case-study intent without stated reasons. “Latest” is a date rule, “SEO” is too broad, and nothing proves that the links serve this reader’s next task.

The cluster contract

A topic cluster is a planned group of pages around one subject. Its pillar is the broad page that organizes the subject; its spokes are narrower pages that answer parts of it. The related content block turns that plan into actual HTML links:

• Every spoke links up to its pillar. This tells readers where the narrow answer belongs and prevents the spoke from becoming an isolated endpoint.
• The pillar links down to every current spoke. When the cluster has more than six spokes, use organized sections in the pillar body rather than forcing the complete set into one related-content block.
• Lateral links connect one spoke to another only when a reader can state the next-step relationship. Sharing a parent is not sufficient.
• Every edge is bidirectional when both directions help a reader. The reverse anchor and reason may differ because the journey differs.
• Removing, merging, or redirecting a page triggers a review of every stored edge that points to it.

Within this playbook, a post-type page links to the elements it requires and to the business types that adapt it. An element page links back to the post types that use it. Those relationships are generated from reviewed frontmatter under the cross-pillar rules: this page’s postTypes array is the source for its post-type links, while the corresponding post-type metadata supplies the return edge. Generation handles rendering; editors still decide whether the relationship belongs in metadata.

The wider element writing rules govern how that metadata remains portable. Never repair a missing editorial relationship by adding a tag and hoping a widget chooses correctly.

Anchor text rules

Anchor text is the visible, clickable wording of a link. Write it so a reader can predict the destination without reading the URL. “Build a how-to guide” is useful; “read more,” “click here,” “learn more,” and a naked URL are not.

Vary anchors naturally while preserving the destination’s subject. “Create a how-to guide” and “structure an instructional guide” work; unrelated keyword synonyms do not. Never promise a template, calculator, price, study, or checklist the destination lacks.

Inside the block, title anchors should be unique. If two destinations would use the same title, add the distinguishing audience, method, or outcome. Keep the optional reason outside the anchor so the click target stays concise and assistive-technology link lists remain useful.

Schema markup and accessibility

No special JSON-LD type is required. JSON-LD is a script-based format for structured data, and Schema.org is the shared vocabulary commonly encoded with it. The links normally remain part of the enclosing Article, TechArticle, Product, or WebPage. Do not invent a RelatedContent schema type.

An ItemList may describe the block only when it is genuinely an ordered or named editorial list and site-wide schema policy calls for it. If used, itemListElement must match the visible item order, URLs, and names. Do not add hidden destinations or synthetic ratings. A breadcrumb is a different relationship and must not absorb these links.

Accessibility starts with a <nav> landmark, meaning a region assistive technology can identify as navigation. Give it a visible heading connected through aria-labelledby; ARIA is the set of attributes used to expose interface names and states when native HTML alone needs help. Use a <ul> because the order normally carries no ranking. Preserve visible keyboard focus, make the title the primary link, and avoid nesting an interactive card inside another link.

Thumbnail alternative text must not duplicate the linked title. Use empty alternative text for a decorative thumbnail. When the image contributes distinct information, describe only that information. The block must remain complete with images or JavaScript disabled, and it must not move keyboard focus when recommendations refresh.

Writing rules

Use three to five items by default, two for a narrow fork, and no more than six for a documented small-cluster need. Write a heading of two to eight words, title anchors of three to twelve words, and optional reasons of eight to twenty-two words. Reasons use one sentence, active voice, and a concrete relationship: apply, compare, verify, define, diagnose, or see evidence.

Every item needs a distinct editorial reason in the content model even when the reason is not rendered. Review titles after destination headlines change. Use canonical internal URLs with leading and trailing slashes. Remove tracking parameters, fragments that do not identify stable sections, redirects, and links back to the current page.

Never place advertisements, author biographies, social follow buttons, newsletter forms, tag clouds, unrelated promotions, or source citations inside this element. Do not mix external reading with internal next steps; external evidence belongs in the sources block. Do not use badges such as “best,” “popular,” or “recommended” unless the page defines and supports the selection basis.

Tone should be helpful and specific, not urgent. Avoid “must read,” “don’t miss,” artificial scarcity, and claims that the destination is comprehensive unless its scope supports that word. The block recommends a path; it does not manufacture importance.

Post types that use it

The frontmatter postTypes array is the source of truth for the following cross-pillar relationships.

Not every candidate needs to render on every page. The post type defines the eligible relationship; the page editor selects the destinations that make sense for the actual subject and journey.

QA checklist

• The block appears once, after sources and before the closing call to action.
• The page contains two to five links, or a documented reason for using six.
• Every item has a recorded editorial reason beyond a shared tag, category, or publication date.
• Each anchor predicts what the destination actually delivers and avoids “read more,” “click here,” and similar generic language.
• The set supports the cluster contract: spoke up, pillar down, and lateral only when genuinely related.
• The current URL is excluded, destinations are canonical, and no link relies on a redirect or tracking parameter.
• The related-content frontmatter agrees with the rendered cross-pillar links.
• The block remains readable, navigable, and complete without thumbnails or JavaScript.
• The navigation region has a visible heading and an accessible name; keyboard focus is visible.
• Thumbnails exist, add identifying value, reserve dimensions, and use correct alternative text.
• Reasons add a next-step relationship instead of repeating titles.
• Sources, ads, forms, social links, and unrelated promotions remain outside the block.
• Any ItemList structured data exactly matches the visible items and order.
• Mobile rendering exposes every title and reason without a hidden horizontal carousel.

A reviewer should reject merely plausible links. Each one must be the right next step, express a real architectural edge, and remain clear in HTML.

FAQ

The academy template renders the FAQ entries from frontmatter.