Internal Link Checker

You enter one page. The checker fetches it, follows any redirects, collects every <a href> in the HTML, and keeps the links whose host matches the host the page ended on. It then visits those links breadth-first, in the order they appear in the source, and stops after 12 page requests. Because the queue fills from the start page first, the crawl is in practice the start page plus the first 11 different internal links in its HTML that have no query string. On most WordPress sites those are the logo link and the header menu.

On every page it reaches, it records each internal link: where it sits, where it points, its anchor text and whether its rel attribute contains nofollow. A linked page it visits but that returns 400 or higher, or does not load, is listed as a broken target instead of being crawled. Linked pages it did not visit, up to 40, get a status check: a HEAD request, retried as a GET when the server answers 403 or 405, with 7 seconds each and redirects followed. Links without a query string are checked first. A target counts as broken when the final status is 400 or higher, or when it cannot be reached at all.

The start page is analyzed in full: every internal link on it is recorded and its uncrawled targets are status-checked. The other 11 pages are whatever it links to first, which on a WordPress theme is nearly always the header menu, because the header comes before the content in the HTML.

So pick the start page for its own links. Good choices are a cornerstone post you want to check, a category page whose links you just reorganized, or a post you suspect links to deleted pages. Starting from the home page mostly tells you about your menu, which you already know is linked from everywhere.

If the crawl stops below 12 pages, the start page has fewer than 11 internal links without a query string, or some links failed, redirected to a page already crawled or pointed to files such as PDFs. Failed links are listed under Broken internal targets.

The six numbers count links across every crawled page, so template links (header, footer, sidebar) are counted once per page they appear on.

Each crawled page gets a row. In is the number of other crawled pages that link to it: ten links from one page count once, a page linking to itself does not count, and a link that redirects to the page counts for the page it lands on. Out is every internal link on the page, repeats and self-links included. Rows are sorted with the lowest In first, so the least-linked pages sit at the top.

Read In against the shape of the crawl. A page in the header menu is linked from every crawled page, so it shows an In close to 11. That says nothing about your content. The rows worth reading are the content pages with an In of 1: inside this crawl, only one page links to them.

In this example the useful finding is not a number in the table. It is that the flour guide, which the owner considers a cornerstone page, is linked only from one recipe. The fix is links to it from the other bread recipes, with anchors such as “choosing flour for sourdough” rather than “this guide”.

Anchor text here is the text inside the link, with spaces collapsed and cut at 120 characters. Image alt text and aria-label attributes are not read. Text hidden with a screen-reader-only class is read, because it is in the HTML.

A link counts as generic when its whole text, ignoring case, is one of 13 phrases: click here, here, read more, more, learn more, this, link, this page, this post, this article, see more, find out more and continue reading. “Read more about proofing baskets” is not generic. A Read more link with a descriptive aria-label still counts, because the checker sees only the visible words.

Two sources make the case for descriptive anchors. Google’s link best practices ask for anchor text that is descriptive, reasonably concise and relevant to the page it links to. WCAG 2.4.4, Link Purpose (In Context), a Level A requirement, asks that each link’s purpose be clear from its text and surrounding context. Screen reader users often move through a page by its list of links, where twenty Read more entries sound the same.

Most used anchor text shows the 15 most common anchors across the crawl. Menu labels top it. Look below them for one phrase repeated on links to several different pages, or a keyword phrase used as the anchor on every link to one page.

An empty anchor is a link with no text inside it. On WordPress sites nearly all of them are linked images (the logo, featured image thumbnails on archive pages, product images) and icon links (social icons, a search toggle, a cart icon).

Because the checker does not read alt text, a linked image counts as empty here even when its alt text is good. That matters, since Google uses a linked image’s alt text as its anchor text, and screen readers announce it as the link’s name. So treat Empty anchors as a list to verify, not a list of errors. The alt text checker flags exactly the case that is a problem: an image that is the only content of a link and has empty alt.

Icon links need a name too. The Social Icons block gives each icon a label setting for this. In a classic theme, the icon usually needs an aria-label on the link or hidden text inside it, which is a theme setting or a template edit.

rel="nofollow" on a link to your own page asks Google not to use that link. Since March 2020 Google treats nofollow as a hint for crawling and indexing, so it does not reliably keep a page out of the index; noindex does that. What it does reliably is throw away the signal from a link to a page you probably want found.

Not every internal nofollow is a mistake. These are the usual sources on a WordPress site, and what to do with each.

Menu settings apply site-wide, so one nofollow on a menu item shows up on all 12 crawled pages: a Nofollow internal count that is a multiple of the pages crawled points to the menu.

Each entry reads status — URL, for example 404 — https://example.com/old-recipe/, with the crawled pages that link to it under Linked from. An entry with a message instead of a number could not be reached at all.

Linked from tells you where to look. When it lists every crawled page, the link is in the template: the menu, a widget, the footer, or a synced pattern. When it lists one or two pages, the link is in their content: open them in the editor and search for the slug. The broken link checker does the same for external links.

The best fix is to edit the link to point at the right page. If the old address has links from other sites or still gets search traffic, also add a 301 redirect from it: Rank Math SEO → Redirections, Yoast SEO Premium → Redirects, or the Redirection plugin under Tools → Redirection. Update your own links even after adding the redirect, so visitors skip the extra hop.

An orphan page is one that no other page on your site links to. A crawl cannot find one: every page after the first is reached by following a link from a crawled page, and a link that redirects counts for the page it lands on. So the only row that can show an In of 0 is the start page, when no other crawled page links back to it.

The closest thing inside the crawl is a content page with an In of 1: only one of the pages reached links to it. That is worth a look when the page matters to you, as in the flour guide example above.

You find real orphans by comparing a full list of your pages with the pages that receive links. The sitemap URL extractor produces that list, and its guide walks through the comparison with Search Console’s Links report.

Crawl depth is the number of clicks from the home page to a page. This checker does not measure it, and Google publishes no depth limit. What Google does document is that it finds pages mainly by following links, so a page you care about should be linked from pages Google already crawls often, not only from page 14 of your blog archive.

You can estimate it by hand. From the home page, click your way to an older post the way a visitor would: menu, category, then Next page until it appears. Each click and each archive page is one level. If you pass page 3 of an archive, the post is deep, and it is probably linked from nowhere but that archive.

Adding links across hundreds of old posts is slow by hand. RankHive reads your Search Console data, finds posts that should link to each other, and drafts the links with their anchor text; you approve each one before its plugin writes it into WordPress.

After you add links, re-run the checker from the same start page: the target’s In count should rise and your generic anchors fall. Google takes longer. In Search Console, Links → Internal links → Top linked pages shows how many internal links Google counts to each page, and it updates as Google recrawls the pages that now carry the link. URL Inspection on the target page lists a referring page under Discovery once Google has seen one.

If your links are added by JavaScript, check that Google sees them: run URL Inspection on the linking page, choose Test live URL, then View tested page, and search the rendered HTML for the link.

Leave these alone: nofollow on Reply and Add to cart links; empty anchors that are linked images with good alt text; high In counts on menu pages; and low In counts on pages that do not need to rank, such as privacy, terms and login pages.