Why Internal Link Plugins Slow Down WordPress
Finding good internal linking opportunities means comparing every post on your site against every other post, looking for overlapping topics and relevant phrasing. That's a genuinely heavy computation once you have more than a handful of posts, and where a plugin chooses to do that work has a real effect on how your site performs.
The common approach: scanning on your own server
Many internal linking plugins do all of their matching directly inside your WordPress installation, using your own database and your own server's CPU. To find candidate links, this typically means querying your posts table with pattern-matching searches across post content, repeated for every post you have. A library of a few dozen posts might not be noticeable. A library of a few hundred or a few thousand is a different story: the amount of comparison work grows with your content, right at the point where your site should be getting easier to maintain, not harder.
Why this becomes a real problem
- Shared hosting has limited headroom. Most WordPress sites run on shared or modestly provisioned hosting, where CPU and memory are limited resources shared across other processes. A heavy scan can visibly compete with whatever else the server is doing at the time, including serving pages to actual visitors.
- It scales the wrong direction. The more you publish, the more expensive each scan becomes, which is backwards: growing your content library should make internal linking more valuable, not more costly to maintain.
- Database bloat adds up. Plugins that cache large amounts of intermediate matching data in custom tables inside your WordPress database add to backup size, migration time, and general technical maintenance overhead over time.
Under the hood, local plugins usually run SQL queries with heavy LIKE %keyword% pattern matching across the wp_posts table. On large databases, this bypasses standard MySQL indexing, forcing full table scans that lock resources and slow down admin page loads.
The alternative: processing off-site
A different approach is to keep the heavy comparison work off your WordPress server entirely. Instead of scanning your full database in place, a plugin can send the lightweight information actually needed for matching, things like post titles, permalinks, and short text excerpts, to a separate backend service built to handle that kind of processing. Your site's own server only has to make a small request and display the results, rather than run the comparison itself.
This isn't free of trade-offs
Sending anything off your server is a legitimate thing to be thoughtful about, and it's worth checking exactly what a plugin sends and what it keeps. A well-built off-site approach should only need metadata, not your full post content, and should be transparent about what leaves your server. It's also worth knowing that this approach depends on that external service being reachable, though a plugin built around it should degrade gracefully rather than blocking your site if the service is briefly unavailable.
How to tell which kind of plugin you have
- Check whether your admin area gets noticeably slower right after installing or running an analysis, especially on a larger site.
- Look at your host's resource usage around the times you'd expect the plugin to run, such as right after publishing a post or triggering a bulk analysis.
- Check the plugin's documentation or privacy policy for whether it mentions sending data to an external service. If it does, the heavy lifting is likely happening elsewhere.
Where OrdoLink fits in
OrdoLink is built around the off-site approach described here. Post titles, permalinks, and excerpt metadata are sent to the OrdoLink backend for analysis, rather than running that matching work inside your WordPress database. The full body of your posts stays on your own server. You can read exactly what is and isn't sent in our Privacy Policy, and more about how installation and analysis work in the documentation.