A bulk interlinking pass failing partway through is one of those problems that looks small in the moment and gets expensive the longer it sits unnoticed. Auto-Interlinking is designed to run across a large batch of posts at once, choosing link targets algorithmically and embedding them without anyone manually deciding where each link should go — which is exactly why a partial or mis-targeted run is easy to miss. Nobody is reading every post by hand to confirm the links look right, so a batch that stalled at post 340 of 600, or one that finished but linked a chunk of posts to the wrong targets, can sit there for weeks looking like normal site content.
This post walks through what a failed bulk interlinking pass actually looks like in practice, how to tell the difference between a partial run and a mis-targeted one, and the specific recovery steps — using the audit view, re-running a scoped batch, and cleaning up through the manual Connect workflow — that get a site back to a known-good state without re-running the entire link graph from scratch.
What "Failed" Actually Means for a Bulk Interlinking Job
Failure isn’t usually a single dramatic error message. In practice it tends to show up as one of three distinct patterns, and they call for different fixes. The first is a stalled batch — the job processed some fraction of the target posts and then stopped, usually because of a timeout on a particularly large post, a transient API hiccup, or a scope that was larger than the job runner’s expected window. The second is a completed-but-wrong run, where every post in scope got links inserted, but the algorithmic target selection picked poor matches — thin pages, outdated posts, or content that’s only tangentially related to the anchor text used. The third is a duplicate-insertion run, where a batch that partially succeeded got re-triggered without the tool recognizing which posts already had links from the first pass, resulting in posts with two or three internal links stacked into the same paragraph where one was intended.
Distinguishing between these matters because the recovery path is different for each. A stalled batch just needs to finish the remaining scope. A mis-targeted batch needs the bad links identified and replaced, not just supplemented. A duplicate-insertion batch needs deduplication before anything else, or a second cleanup pass will just be untangling its own mess on top of the first mess.
A few signals tend to show up together when something has gone wrong with a bulk pass, and it’s worth knowing them before diving into the audit view so you’re not searching blind:
- A run that reports completion but touched noticeably fewer posts than the scope you defined
- Anchor text that reads naturally but links to a post with little topical relationship to the sentence around it
- Two or more links to the same or near-identical targets sitting inside the same paragraph
- A cluster of posts published or updated around the same date all missing links entirely, while posts before and after that window look normal
Reading the Audit View Before Doing Anything Else
The audit view is the first stop, and skipping it in favor of just re-running the batch is the single most common way a recovery makes things worse instead of better. It shows, per post, which posts were touched in the run, what anchor text was used, which target URL each link points to, and a timestamp for when the link was inserted — which is enough to reconstruct exactly where a stalled batch stopped and exactly which posts got which links in a mis-targeted run.
The detail that matters most here is the timestamp column, because it lets you separate “links from this failed run” from “links from a previous, healthy run” even when they’re sitting in the same post. Without that distinction, a cleanup effort risks stripping out perfectly good links that happened to be adjacent to bad ones just because they’re hard to tell apart by eye. Sort the audit view by run timestamp first, isolate the specific batch that failed, and only then start deciding what needs to change.
Confirming Where a Stalled Batch Actually Stopped
For a stalled batch, the audit view’s post list is the ground truth for scope, not whatever number the job dashboard reported when it errored out. It’s common for the reported failure point to be off by a handful of posts either direction, because the job can fail mid-write on one post while the dashboard counter was already incremented for the next one in the queue. Cross-referencing the actual list of touched posts against your full post list for that category or date range gives you the real remaining scope — the posts that still need a pass — rather than trusting an approximate count.
Once that remaining scope is confirmed, re-running Auto-Interlinking against just that subset, rather than the original full batch, avoids re-touching posts that already succeeded and avoids the duplicate-insertion problem entirely. This is the most common recovery case in practice, and it’s usually the least disruptive one — the fix is almost entirely about correctly identifying scope, not about undoing anything.
Fixing a Mis-Targeted Run
Mis-targeted links are the least forgiving failure mode because they don’t announce themselves — the post reads fine, the link works, it just points somewhere that doesn’t actually serve the reader or the topic. This tends to happen when the algorithmic target selection runs against a content set with a lot of thin or near-duplicate posts, where multiple candidate targets score similarly and the selection picks one that’s technically relevant but not the best available match, or an outdated post that’s since been superseded by a better-targeted piece.
The audit view’s target URL column, cross-referenced against a quick manual read of the anchor text in context, is usually enough to flag these — an anchor like “site health checklist” pointing to a post about an unrelated topic stands out fast once you’re looking at run-scoped data instead of scanning random posts. For each flagged link, the fix isn’t to delete it and leave the anchor text unlinked; it’s to replace the target through the manual Connect workflow, which is the same tool used to cover pages the algorithmic pass misses entirely, and works just as well for correcting a bad target as for adding a missing one.
Cleaning Up Duplicate Insertions
Duplicate insertions are the messiest of the three failure modes because they compound — a paragraph with two links to the same target, or two different targets both trying to claim the same anchor phrase, reads as noticeably over-linked to a reader even before you get into whether either link is well-chosen. The audit view’s timestamp column is essential here, since it’s the only reliable way to tell which of the duplicate links came from the original run and which came from the accidental re-trigger.
The general rule for cleanup is to keep the earlier-timestamped link if its target is reasonable, and remove the later duplicate rather than picking arbitrarily, since the earlier link is more likely to reflect the state of your content graph at the time the anchor text was chosen. If neither duplicate is actually a good target — which does happen — this becomes a mis-targeted-run cleanup on top of a duplicate cleanup, and it’s worth treating those as two sequential steps rather than trying to solve both at once, if only because it keeps the audit trail of what changed and why easier to follow later.
Re-Running Auto-Interlinking Without Repeating the Failure
Before re-running any batch, it’s worth narrowing scope more aggressively than feels necessary — a re-run against a smaller, well-defined set of posts, confirmed against the audit view, is far easier to verify afterward than a re-run against the same broad scope that failed the first time. If the original failure was a timeout on large posts, consider whether the batch can be split by post length or word count rather than by date range, since that’s more likely to isolate the specific condition that caused the stall in the first place.
It’s also worth checking, before re-running, whether the underlying cause was something environmental rather than something about the content itself — a plugin conflict, a temporary API rate limit, a server resource constraint during a high-traffic window — because re-running into the same environmental condition just reproduces the same failure. If the audit view shows the stall happening at a consistent point across more than one attempt, that’s a signal to look at infrastructure before blaming content — and it’s worth logging the batch size, scope definition, and failure point each time, since a pattern that isn’t obvious after one failed run often becomes obvious after two or three.
What the Manual Connect Workflow Is For in Recovery, Specifically
The manual Connect workflow exists in the first place to cover pages that Auto-Interlinking’s algorithmic selection misses — new pages without enough signal yet, or pages in a content area too small for the algorithm to confidently match against. In a recovery context, it does double duty: every mis-targeted or duplicate link identified through the audit view gets corrected through the same interface, rather than needing a separate bulk-edit tool. That consistency matters because it means the recovery workflow isn’t introducing a new tool with its own quirks into an already messy situation — it’s the same manual override you’d use in the ordinary course of filling algorithmic gaps.
Using Connect for recovery also has the side benefit of building a manually-verified link on exactly the posts most likely to need one anyway, since a post that got a bad automated link is often a post the algorithm generally struggled to place — thin content, an unusual topic, or a page sitting outside your typical internal linking patterns. Fixing the immediate problem often surfaces a structural content gap worth addressing separately.
Preventing the Next Failed Pass
The most reliable prevention is running interlinking batches in smaller, more frequent scopes rather than large infrequent ones — a weekly pass against newly published posts is far less likely to time out or mis-target than a quarterly pass against six months of accumulated content, and any failure in a small batch is both easier to spot in the audit view and cheaper to recover from. It’s also worth checking the audit view on a normal cadence even when nothing seems wrong, since the whole premise of this failure mode is that a bad run doesn’t look different from a good one at a glance.
For a broader view of how interlinking recovery fits into the rest of the publishing and site-health workflow, see Publishing, Distribution, and Site Health: The Complete Guide.
