How to Use Semantic Similarity to Suggest Internal Links and Check the Suggestions

When you manage a website with many pages, it can be hard to spot where one page should link to another. Semantic similarity measures how closely pages or passages discuss related ideas. A tool compares numerical representations of the text and gives you a shortlist to review.

Use that shortlist to find possible links, not to publish links automatically. A high score does not show that readers need the destination or that a link fits the sentence. You still need to check the connection, the anchor text, and the destination. The method can make an internal-link audit easier to review, but the available research does not establish that similarity-based linking improves rankings or traffic.

What a similarity score tells you

A semantic-similarity tool turns text into numbers that capture aspects of its meaning. Sentence embeddings are numerical representations of sentences. They form vectors, and a common comparison method called cosine similarity measures how closely the vectors point in the same direction. The Sentence-BERT research describes sentence representations designed for this kind of comparison.

A similarity score ranks text according to the method and model used. It is not a probability that a link is useful. Two pages can score highly because they cover the same broad topic, even if they answer different questions or repeat each other. A lower-scoring pair can still contain a useful connection between a specific section and a specialized page.

For search engine optimization (SEO), semantic similarity works best as a way to find possible internal links. It narrows a large set of page pairs so a person can decide which ones deserve attention.

Generate candidates from pages and passages

Start with a list of the site’s important pages. A site crawl, sitemap, or content export can provide the URLs. Follow redirects, which send visitors from one URL to another, and identify canonical URLs, the preferred versions of pages. This keeps one page from appearing as several different candidates.

Next, compare meaningful page text. Page titles and meaningful body text are useful starting points. Repeated navigation and footer text can make unrelated pages appear similar. A whole-page comparison is a simple first pass. For long articles, compare sections or paragraphs as well. Passage-level comparison can reveal a relevant connection that the overall subjects of two pages would hide.

A tool then turns each selected passage into a numerical representation using the same method and ranks page pairs by similarity. Remove self-matches and duplicate pages. Also remove unsuitable destinations and links that already exist. Show reviewers the source passage and the relevant destination passage alongside the score. A bare list of URL pairs gives too little context to judge the suggestion.

Research on automatic link generation has examined both document-level and passage-level matching. One 2010 study used Wikipedia pages and a different text-comparison method from modern sentence embeddings. Its results show why reviewers should compare passages and inspect suggestions, but they do not establish a score cutoff or expected performance for a current website.

Decide whether each suggestion helps a reader

Review the top candidates and ask what a reader gains by following each link. The destination should answer a likely next question, explain a term, or provide relevant detail that the source page does not already give. If the two pages merely repeat the same point, linking them may add little.

For each candidate, note the source URL and passage, then the destination URL and passage. Record the score and method, whether a link already exists, and whether you will add, reject, or investigate the suggestion. If you accept a candidate, write a sentence where the link fits naturally. Use anchor text that tells readers what they will find at the destination. Do not insert a link just to repeat the destination page’s target keyword.

There is no universal score cutoff for accepting a link. Scores depend on the model and text being compared, so test candidate results against examples from your own site. Review high-ranked candidates for duplicates and broad topic overlap. Also inspect some lower-ranked pairs for useful connections between specific sections. Record why you reject suggestions; those decisions help you see which kinds of matches produce poor candidates.

Check the link after adding it

Check the link in the page's HTML (the code that defines the page) and check the destination, not just the candidate report. Google says it can generally crawl links written in the page's HTML as an <a> element with an href attribute, which specifies the destination URL. Its link guidance also recommends descriptive, concise anchor text and relevant context around the link.

Confirm that the link points to the intended URL and that the destination loads as expected. Check redirects to make sure they do not send readers somewhere unexpected. Then read the surrounding paragraph: the anchor should make sense in that sentence, and the destination should meet the expectation the anchor creates. A crawler, which scans pages and links, can help check URLs and link paths. A link-audit tool can help too. Also inspect the page as a reader.

For a wider check, Google Search Console’s Links report can show internal links Google has found pointing to a page. Google describes the report as a sample of links found over time, so it is not a complete live inventory of every link on the site. Use it as a supplementary check alongside a current site crawl and page-level review. URL Inspection can provide Google-specific information about a URL, but it does not replace checking the link in your own page markup.

A successful request to a URL proves that the request received a response. It does not prove that Google crawled the page or added it to its search index. Google’s documentation on HTTP status codes explains that a successful response does not guarantee indexing.

Where similarity suggestions fail

Shared vocabulary can produce a convincing score for an unhelpful link. Two pages may mention the same product or concept while making different points. Research on sentence-transformer representation bias found that shared nouns can strongly influence similarity scores, sometimes more than whether sentences express the same relationship. Treat the score as a clue about related language, then check what each passage actually says.

A long article can contain useful sections, but comparing the whole page can hide their match among unrelated text. Comparing passages can help, but it creates more candidate pairs, including more irrelevant matches to review. Near-duplicate pages create another problem: a strong match may indicate that the pages overlap too much, not that they need a link between them.

The result depends on the model that turns text into numbers and on which text the system extracts from each page. How that text is divided into passages also affects the result. A score from one setup does not transfer directly to another. Keep the method consistent while reviewing candidates, and do not treat one threshold as a rule for every site.

Finally, a link that works does not prove that a search engine has found, added to its index, or ranked the destination. Google’s guidance supports crawlable links and useful anchor text; it does not prescribe similarity scoring or promise a ranking benefit from this approach.

Key Takeaways

• Use similarity to shortlist pages: A score ranks related text, but it cannot decide whether a link helps readers.
• Review passages, not only whole pages: Long pages can contain useful connections that page-level comparisons miss.
• Check the link in context: Confirm the destination, the actual href link, and anchor text that accurately describes the destination.
• Treat search reports as partial evidence: Search Console’s Links report is a sample, and a successful page response does not prove indexing or ranking.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com