Skip to content

Related posts

Related posts that are actually related.

Most related-post plugins match tags, which is why they recommend something from 2019 about a different subject entirely. Linkilo picks by meaning, using the same content understanding that powers its link suggestions, and precomputes the result so it costs nothing on the page a visitor loads.

Matched by meaning, not tag overlap Precomputed and cached Tracked, so you can see if it works

Included in every plan. 30-day money-back guarantee.

Layout

Four layouts, each the plugin’s own template. Thumbnails, excerpts, categories and reading time are each a checkbox.

The job, as it stands

What a related posts plugin for WordPress gets wrong

Pick what to show under each post. Or install something that shows whatever shares a tag, and watch it recommend a post from 2019 about something else.

By hand, that means

  1. Read the post and decide which three or four others a reader should see next.
  2. Check those posts still exist and are still current.
  3. Add the block and set it by hand, post by post.
  4. Revisit it when you publish something closer to the subject.

Linkilo does every step of that.

What it costs to leave it

A related-posts block that recommends the wrong thing is worse than none. The reader tries it once, lands somewhere irrelevant, and from then on it is furniture: a slot at the bottom of every article, spent on nothing.

Somebody has to do that: you, or somebody you pay.

What you get back

The picking, and the maintenance as the archive grows.

What it looks like instead

The block under each post shows things that are actually related, because relatedness is measured from the writing rather than from the tags.

How soon

On as soon as the module is enabled.

Who does the work

AI, inside deterministic guardrails

Related-by-meaning uses the same embeddings as the suggestions; the rendering, caching and placement are ordinary deterministic WordPress.

Time figures describe the shape of the job (an afternoon, a day, a week), not a promise about your site. Your archive is your archive.

The problem

They finished the article. Then you offered them nothing worth clicking.

The reader was interested enough to reach the end, which is the hardest part. That is the moment most sites hand them three random posts chosen by a tag they happened to share, and watch them leave.

What a tag-matching block does

  • Picks whatever happened to share a tag, which is often nothing to do with the topic
  • Recommends the same three popular posts under every single article
  • Runs an expensive query on every page load to do it
  • Looks broken on mobile, because it was styled in 2018
  • Gives you no way to know whether anybody ever clicks it

What this one does

  • Chooses by semantic similarity and topic-cluster membership
  • Genuine variety, because it understands what each post is actually about
  • Precomputed and cached, so nothing runs when a visitor arrives
  • Responsive from a phone to a wide desktop, inheriting your typography
  • Tracked by click analytics, so you can prove it earns its space
What you would want to know

A block at the bottom of every article deserves scrutiny

“How does it choose?”

Semantic similarity as the primary signal, topic-cluster membership weighted up, and historic click-through as a tiebreaker between close candidates.

“Will it slow my pages down?”

No. Matching runs in the background on WP-Cron and the result is cached, so a visitor gets a stored list rather than triggering a similarity calculation.

“Can I put it where I want?”

Automatically after the content, placed manually as an editor block, or via shortcode for custom templates. Configure how many to show and how they lay out.

“Can I exclude things?”

Exclude individual posts, whole post types or categories from ever being suggested. The current post is always excluded automatically.

“Do these count as internal links?”

They are real links in the page, so yes. They also appear in click analytics, which is how you find out whether the block does anything at all.

“Can I favour certain pages?”

You can weight toward top performers where you want traffic concentrated, or leave it purely relevance-driven. Both are legitimate depending on what the block is for.

“What about posts already linked in the body?”

Optionally excluded, so the block offers something new rather than repeating a link the reader already scrolled past.

“Does it need an API key?”

For the semantic matching, yes, and it reuses embeddings already computed for link suggestions rather than costing anything extra. Without a key it falls back to keyword and cluster matching.

“Will it look like my site?”

It inherits your theme’s typography rather than imposing its own, and the layout is configurable, so it reads as part of the page rather than a plugin someone installed.

How it works

Better matching, cheaper rendering

Matching

It already understands your posts

The related-post picker reuses the content understanding built for link suggestions: embeddings, keywords, intent and cluster membership. That work has already been done, so relevance here comes free rather than from a second, weaker matching system bolted on the side.

It is why the suggestions vary properly. A tag matcher shows the same three popular posts everywhere because tags are coarse; a semantic matcher can tell that this particular article is about seasoning rather than buying, and recommends accordingly.

  • Semantic similarity, not tag overlap
  • Topic-cluster membership weighted into the score
  • Historic click-through as a tiebreaker
  • Current post and anything you have hidden always excluded
Why these three

Semantic similarity primary signal

Same topic cluster weighted up

Historic click-through tiebreaker

Already linked in body optionally excluded

Tag overlap is not part of the calculation at all.

Performance

Zero cost on the page a visitor actually loads

Matching runs in the background and the result is cached. A visitor requesting your article does not trigger a similarity calculation; they get a stored list.

That is the difference between a related-posts feature that is pleasant and one you can leave enabled during a traffic spike. The typical tag-based plugin runs a query per page view, which is exactly the wrong shape for a page that is about to be hit hard.

  • Matching runs on WP-Cron, never on a page request
  • Results cached and invalidated when content changes
  • No external requests at render time
  • Embeddings reused from link suggestions, so no extra API cost
Cost at render time

Typical tag-based plugin 1 query per view

Linkilo related posts cached list

Matching happens in the background, in batches, on cron.

Proof

Finally, a way to know whether the block works

Almost every WordPress site has a related-posts block, and almost nobody knows whether it does anything. It has been sitting at the bottom of every article for years on faith.

Because these are real internal links, click analytics tracks them like any other. You can see the block’s click-through rate, which recommendations pull and which never get touched, and decide whether it deserves its place or needs rethinking.

  • Every recommendation tracked by click analytics
  • Per-destination click-through rates
  • Compare the block against in-body links for the same destination
  • Zero-click recommendations surfaced for review
Block performance

Related-posts block 6.4% CTR

In-body contextual links 11.2% CTR

Both worth having. Now you know which is doing more.

Who this is for

Who gets the most out of this

Publishers chasing pages per session

Readers finish one article and leave.

With Linkilo: the next article offered is one they actually want.

Anyone on an old related-posts plugin

It is slow and its suggestions are close to random.

With Linkilo: better matching and nothing runs on page load.

Ecommerce content

Guides never point at the next step in the process.

With Linkilo: funnel stage is one of the signals it matches on.

Sites on modest hosting

Every extra query on page load hurts, and this is on every page.

With Linkilo: the list is precomputed and cached, so it costs nothing.

Large archives

The same popular posts get recommended under everything.

With Linkilo: semantic matching surfaces deep content that tags never would.

Anyone who measures

The block has never been evaluated because it could not be.

With Linkilo: click data tells you whether to keep it, move it or rethink it.

What it costs to run

The numbers that matter for a block on every page

0
Queries on the page a visitor loads
0
Extra API cost, embeddings are reused
3
Signals: similarity, cluster, click-through
Tracked
Every recommendation, by click analytics
How it compares

Every WordPress site has this block. Almost none of them measure it.

Linkilo related posts compared with a typical tag-based plugin
Capability Linkilo Typical related-posts plugin
Shows related posts Yes Yes
Matched by meaning, not tags Yes No
Topic-cluster aware Yes No
Precomputed and cached Yes Varies
Zero queries at render time Yes No
Excludes posts already linked in the body Yes No
Click-through tracked per recommendation Yes No
Inherits your theme typography Yes Varies
Block, shortcode or automatic placement Yes Varies
Works with no AI key Yes Yes

The tracking row is the one people underestimate. See click analytics for what it tells you.

Getting started

Three steps to a block that earns its space

  1. Enable and place it

    Automatically after the content, as an editor block, or via shortcode. Choose how many to show and how they lay out.

  2. Let matching run

    Recommendations are computed in the background and cached, reusing the embeddings already built for link suggestions.

  3. Check whether it works

    Click analytics tracks every recommendation, so after a fortnight you know its click-through rate rather than assuming.

Questions about the block

You can, but there is little reason to. This uses better matching signals and costs nothing at render time, and running both would simply show two blocks doing the same job.

Give readers somewhere worth going next.

Recommendations chosen by meaning, precomputed so they cost nothing to render, and measured so you finally know whether the block works.

30-day money-back guarantee. Every feature is included in every plan.