How to Use AI for Internal Links Without Inventing URLs

A blog with three dozen posts and no internal linking strategy is a common, fixable problem. Reading all three dozen posts yourself to find natural link opportunities is not a realistic workflow.

Asking an AI tool to suggest internal links from a topic summary alone is faster, but it introduces a new risk where the model will confidently suggest a URL that sounds exactly right and does not exist.

The fix is not to avoid AI for this task but to never let the model invent the one piece of information it cannot know on its own, which in this case is your actual URLs.

Why this fails when done the obvious way

If you ask a general-purpose AI tool "suggest internal links for an article about email deliverability" without giving it your site's actual content, it will generate URLs that follow a completely plausible pattern, something like [yoursite.com/blog/email-deliverability-guide], because that is what URLs on topics like this usually look like.

It has no way to know whether that page exists on your site. It will suggest it anyway, with total confidence, because generating a plausible-looking URL is not different from generating a plausible-looking sentence.

The fix is to never ask the model to produce a URL from memory. Only ever ask it to choose from a list you provide.

Step one: build a verified URL inventory

Before any linking suggestion happens, you need a table of what actually exists. This does not require reading every article in full. A title, a URL, and a one-sentence summary of what the article actually covers is enough.

Every URL in this table has been opened and confirmed to load. The entire point of the exercise is to ensure the model was never asked to supply a URL, only to pick one from a list you have already verified.

Step two: ask for suggestions from the list only

Prompt: "Here is a table of existing articles with their URLs and topics. Here is the draft of a new article about [topic]. Suggest which existing articles would be relevant to link to from this draft, using only the URLs in the table. For each suggestion, quote the sentence in the new draft where the link would go, and explain in one sentence why that existing article is relevant there. If nothing in the table is genuinely relevant, say so instead of forcing a suggestion."

This does three things at once:

• It restricts the model to real URLs.
• It forces a stated reason for each suggestion, which surfaces weak matches.
• And it explicitly gives permission to suggest nothing, which removes the incentive to force a link where none belongs.

Three outcomes from one draft

Running a new draft about "improving email open rates" against the table above produces three different kinds of results, and only one of them should pass as written.

1. A relevant suggestion: Link "Why Your Emails Land in Spam" from the sentence discussing why some campaigns underperform regardless of subject line quality. The stated reason: deliverability problems are a common, related cause of low open rates that this article's reader has probably not considered. This is a good link. It sends the reader somewhere genuinely useful.
2. A forced suggestion to reject: Link "A Beginner's Guide to Cold Outreach" from a sentence about subject line testing. The stated reason given is that "both articles are about email." That is true and also not a real connection. Cold outreach sequencing and subject line testing solve different problems for different readers. This suggestion should be rejected even though it technically follows the instructions, because the model will sometimes manufacture a thin justification rather than reporting no good match.
3. An invented URL to reject outright: If a suggestion appears referencing a URL not in your table, for example [/blog/subject-line-testing-guide,] stop and treat it as a hard failure of the process. It means the instruction to use only the provided list was not followed, and every other suggestion in that response now needs to be checked against the table by hand before you trust any of it.

The review pass

Before any suggested link is added to a live page, confirm three things:

• The URL appears in your verified inventory
• The linked article's actual content matches the one-sentence reason given
• And the anchor text describes the destination rather than repeating the exact page title mechanically.

This takes a minute or two per suggestion, and it is what turns "AI suggested some links" into "these links were checked and are correct."

Why this is worth doing at all

A blog with strong internal links helps readers find the next relevant thing to read, and it helps search engines understand which pages on your site relate to which topics. Neither benefit exists if the links are wrong, missing, or pointing at pages that do not exist. The verification step is the part that makes the linking actually useful instead of merely present.

How Weelkit approaches this

Because Weelkit already knows what you have published, link suggestions are proposed against your actual site inventory rather than a topic description typed into a chat window, and asset and publishing history stay attached to the article they belong to.