Nearly every WordPress blog ends up with a related posts block, usually because a theme shipped one or a plugin promised “more pageviews and better SEO”. Then a year passes, nobody checks whether it did anything, and it just sits there rendering six thumbnails. Here’s our honest answer: it helps less than you think for rankings, more than you think for crawling, and it can quietly cost you real server time if the plugin behind it is naive.<\/p>\n
Stripped of the styling, a related posts block is a query. When someone loads an article, your site runs a second query to find other posts it considers similar, then prints them as links. Everything interesting comes down to two questions: how does it pick the posts, and what does that query cost you?<\/p>\n
The most common method. The plugin looks at the current post’s categories and tags, then pulls other posts that share them, ordered by term overlap or by date. It’s cheap-ish, predictable, and you control it directly: fix your taxonomy and the related posts fix themselves. The downside is that it inherits every flaw in that taxonomy. If you have one category called “Blog” with 400 posts in it, this method means “here are six random posts”, and if you tagged inconsistently, which most sites do after a couple of years, the results get noisy.<\/p>\n
Here the plugin compares the actual words in the title and body, either through MySQL fulltext indexes or, in the worst implementations, a The “people who read this also read that” approach, driven by your own visitor data or a third party service. With enough traffic it surfaces pairings no editor would have guessed, because it reflects what people do rather than how you filed things. The tradeoffs are real. It needs volume to mean anything, so a new blog gets noise. It usually needs either a tracking table you maintain or an external service, which adds a request and a privacy question. And it has a rich-get-richer bias: popular posts get recommended everywhere, and the ones that most need links get none.<\/p>\n Related posts are internal links. That’s the whole mechanism, and there’s no separate “related posts ranking factor”. So the useful question is: what do those links do, and how much of it does a template block at the bottom of the page deliver?<\/p>\n Links inside a site do three jobs: they help search engines discover pages, they influence how crawl attention and link value flow around, and they pass context about what a page is about.<\/p>\n A related block does the first job well. If a post has nothing else on your site linking to it, and the block starts surfacing it, that post now has a path in. That’s genuine and measurable.<\/p>\n The second job, it does partially. Links in a block are still links, but they’re template links, in the same place on every article, often pointing at the same handful of posts. Search engines have handled boilerplate navigation, footers and recirculation widgets for a very long time, and they’re good at recognising a repeated template region and weighting it differently from links inside body copy. We can’t quantify that discount, and anyone giving you a percentage is guessing, but the direction isn’t controversial.<\/p>\n The third job is where the block is weakest. Most widgets use the post title as anchor text, or worse, wrap only a thumbnail with no text at all, sitting below the article where readers are least attentive. Compare that to a sentence mid-article saying “we covered how to structure this in our guide to X”. Same destination, completely different quality of signal, and our notes on choosing anchor text in WordPress<\/a> cover that side.<\/p>\n Honest verdict: useful for crawl coverage and session depth, weak for the ranking lift people hope for. Related posts are plumbing, not leverage.<\/p>\n This is the part most articles skip, and the part most likely to actually hurt you.<\/p>\n The query runs on every article view, for every visitor, and by default it runs uncached. Depending on the method that means a multi-table join across Install Query Monitor on a staging copy, load a post as an admin, and open the Queries panel. Queries by component<\/strong> attributes queries to the plugin that fired them, so if your related posts plugin is near the top of that list you have your answer. Slow queries<\/strong>, sorted by time, will expose any leading-wildcard Two things. First, caching: results only need recomputing when content changes, so a well-built plugin stores them in a transient or the object cache. A full-page cache hides the problem for anonymous visitors, which is fine until you have logged-in users or a cache miss storm.<\/p>\n Second, and the proper fix at scale, a precomputed relation table. The plugin works out relationships once on save or on a scheduled job and stores them in its own table, so serving related posts becomes a single indexed lookup by post ID. That’s the difference between the feature costing nothing and costing you your response time.<\/p>\n Orphan rescue.<\/strong> An orphaned post is one nothing on your site links to. It might be in your sitemap, it might even be indexed, but with no internal path it gets almost no crawl attention, and most blogs accumulate these without noticing. A taxonomy-based block, driven by categories and tags rather than by whether you remembered to link somewhere, picks up orphans automatically. Our walkthrough on finding orphaned pages in WordPress<\/a> gives you the before-and-after number you’ll want later.<\/p>\n Old-archive discovery.<\/strong> The natural gravity of a blog is towards recency. Homepage, feed and “latest posts” modules all point forward, so anything from three years ago is reachable only through search or deep pagination. A block that isn’t date-ordered pulls those posts back into circulation, and that’s a job almost nothing else on a default WordPress install does.<\/p>\n Behavioural matching is the weakest method for exactly these two wins, because posts with no traffic generate no behavioural data. The content that most needs rescuing is what it rescues least.<\/p>\n Put a related block and a well-placed in-body link side by side and the in-body link wins on every dimension that matters. It sits in the reading flow, so it gets clicked far more than a footer grid. Its anchor text is a phrase you chose, describing the destination, instead of a truncated title or a bare image. And it’s editorial, unique to that article, rather than a template region repeated on 400 pages.<\/p>\n So if you have an hour to spend on your link structure, spend it adding contextual links to your best posts, not tuning related posts settings. The block is a safety net, not the strategy. The strategy is closer to building topic clusters around a hub page<\/a>.<\/p>\n The obvious objection is that adding contextual links by hand across a few hundred posts is tedious, which is why link-suggestion plugins exist. Full disclosure: JNK Linkweave<\/a> is our own, and it works on the contextual side rather than the related-posts side. It scans your content and suggests in-body links with anchor text you approve, and the free version covers suggestions and manual rules. It does not generate a related posts block, and we won’t pretend it does. If that’s the job you want done, Linkweave<\/a> is worth a look.<\/p>\n This is the mistake that quietly turns the block into zero SEO value, and it’s increasingly common because it gets sold as a performance optimisation.<\/p>\n Some plugins render the block client-side: the initial HTML contains an empty container, and after load, JavaScript fetches the related posts (often via the REST API) and injects them. It’s fast and it looks fine in a browser. The problem is that the discovery benefit, the main thing related posts are actually good for, depends entirely on a real Test it in ten seconds: open a post, view source (the raw source, not the inspector, which shows the rendered DOM) and search for one of the related post URLs. If it isn’t there, your block is doing nothing for crawling. Either switch to server-side rendering or stop counting it as an SEO measure. Same test for infinite-scroll and “load more” modules, which are almost always JavaScript-only.<\/p>\n Internal links report in Search Console.<\/strong> Under Links, it shows how many internal links Google has found pointing at each URL. Export it, then add or fix your block and export again a few weeks later. Look at the bottom of the list: pages that had zero or one link and now have several. That’s the block working. If counts only rise for pages that were already well linked, your matching is rich-get-richer and needs adjusting.<\/p>\n Orphan count before and after.<\/strong> Run an orphan audit, write the number down, make your change, run it again in a month. Cleanest single number, because orphan rescue is the block’s strongest genuine use.<\/p>\n Engagement.<\/strong> Look at pages per session and the click-through rate on the block itself, if your plugin tracks it. Recirculation modules at the bottom of an article typically get modest click rates, so be honest about the baseline. If yours is near zero, the block isn’t earning its screen space or its database time.<\/p>\n One warning: don’t try to read a ranking change out of any of this. Adding a related posts block isn’t the kind of change that produces a clean before-and-after in rankings.<\/p>\n Yes, with modest expectations. Use a server-rendered, taxonomy-based block with caching or a precomputed table, cap it at four to six links, check it in Query Monitor once, then stop thinking about it. What you shouldn’t do is install one, expect a ranking lift, and skip the contextual linking work because you feel the related posts have it covered. They don’t. They cover the posts you forgot. The links that move things are still the ones you write into the sentence.<\/p>\n Not directly, but they can cause indirect harm in two ways. If the plugin runs an uncached, expensive query on every page view it slows your server response, and that does matter. And if the block links out to thin or noindexed pages, you are spending crawl attention on pages that give you nothing back. A cached, server-rendered block with sensible exclusions is harmless.<\/p>\n No, they are a complement rather than a replacement. A hand-placed link inside your body copy sits where readers are actually paying attention, uses anchor text you chose, and carries surrounding context, so it beats a template block on every dimension that matters. The related block is a safety net that catches posts you never got around to linking, which is genuinely useful and genuinely secondary.<\/p>\n Three to six is a sensible range for most blogs. Fewer links keep the block scannable and keep whatever value it passes from being spread too thin, and a shorter list also means a cheaper query. If you are showing ten or twelve, cut it and watch whether your click-through rate on the block changes at all. Usually it does not.<\/p>\nLIKE '%term%'<\/code> scan across post_content<\/code>. Done well, with a fulltext index and a stored score, it beats a broken taxonomy comfortably. Done badly, it’s the most expensive thing on your page: a leading wildcard cannot use an index, so the database reads every post body, every time. On a small blog you won’t notice. At a few thousand posts with real traffic, you will.<\/p>\nBehavioural matching<\/h3>\n
The real SEO mechanism, honestly<\/h2>\n
The performance cost nobody mentions<\/h2>\n
wp_posts<\/code>, wp_term_relationships<\/code> and wp_term_taxonomy<\/code>, or a full scan of post_content<\/code>. With a few hundred posts nobody notices. With several thousand posts, a busy day and cheap shared hosting, this is what makes your time-to-first-byte crawl. It’s invisible in the usual tools too: page speed reports focus on the browser, so a slow query shows up only as “the server was slow to respond”.<\/p>\nHow to check yours<\/h3>\n
LIKE<\/code> on post_content<\/code>. Compare against a page with no related block: the difference is your related posts tax.<\/p>\nWhat fixes it<\/h3>\n
Where related posts genuinely win<\/h2>\n
Where they lose to contextual links<\/h2>\n
A practical setup checklist<\/h2>\n
\n
The JavaScript trap, which deserves its own section<\/h3>\n
<a href=\"...\"><\/code> existing in the HTML you serve. If the links only appear after JavaScript runs, you’re relying on rendering happening, happening reliably, and happening on that page. That’s a much weaker guarantee than a plain link in the markup, and an unnecessary risk.<\/p>\nHow to tell whether yours does anything<\/h2>\n
So, should you use one?<\/h2>\n
Frequently asked questions<\/h2>\n
Do related posts hurt SEO in any way?<\/h3>\n
Are related posts better than adding internal links by hand?<\/h3>\n
How many related posts should I show?<\/h3>\n