Enter one page's address to count every internal and external link it carries, then request up to 50 of its internal links from our server. A link is called broken when it answers a 4xx or 5xx error; a login wall, a refusal, a rate limit or a timeout is reported as could not verify, never as broken.
One page, its links. The page is fetched once as VerandBot/1.0. Every same-site link in the served HTML is counted once per path (query strings and #fragments dropped, www and the bare domain treated as one site). The first 50 unique internal links, in source order, are each requested: HEAD first, GET when HEAD is refused, redirects followed, 6 seconds each.
Any final 4xx or 5xx is broken, the rule Verand's site crawl uses, except a 401, 403 or 429: those, and no answer, are could not verify, because login walls, bot walls and rate limits answer a server differently from a person. A link that redirects to a working page shows the final code and reads as fine. Links to /cdn-cgi/, a path Cloudflare reserves for its own features, are skipped. External links are counted, not requested.
Links built by JavaScript after the page loads. Anchor text and rel="nofollow", which are not reported. Each redirect hop: the Redirect Checker shows those. And anything about your other pages: orphan pages and which pages link here need a full-site crawl, not one URL.
One fetch for the page, one request per link, and one rule for what counts as broken. The card is the tool in motion on an example page, looped, and each step lights up while the card is doing it.
Link /privacy-notice to its new address, or 301 the old path to it.
The tool requests the address you typed as VerandBot, follows redirects, and reads the HTML the server sends back. Nothing runs in a browser, so a menu or tab that JavaScript builds after load is not in what it reads.
Each href on an anchor is resolved against the page. Same site, with www and the bare domain folded together, is internal; anything else is external. Mail, phone, script and #anchor links are skipped, and each path is counted once.
In source order, eight at a time: a HEAD request for each internal link, retried as a GET when the server refuses HEAD, answers 403 or says nothing. Redirects are followed to the end, and each request gets six seconds.
A 404 or 410 says the page is not there; a 500 or 503 says your server could not serve it. The exceptions are 401, 403, 429 and a timeout, marked could not verify, because a login wall or a firewall answering our server is not proof a reader would hit a dead end.
Internal links are the paths a site builds for its own readers and for every crawler that arrives. Here is what they carry, what breaks them, what a single-page check can and cannot tell you, and why a dead footer link matters more on a regulated site.
An internal link is an anchor on one page of your site that points at another page of the same site. /fees, https://yourdomain.com/fees and https://www.yourdomain.com/fees are the same link as far as this checker is concerned: relative paths are resolved against the page, and www and the bare domain are folded into one site. A link to blog.yourdomain.com or app.yourdomain.com is a different host, so it is counted as external. Links that start with mailto:, tel: or javascript:, and jump links to a #section of the same page, are not links to another page and are skipped.
Each path is counted once. A footer that repeats the header's "Contact" link, or /fees?ref=nav beside /fees, adds nothing to the count, because the question is how many distinct pages this page points at, not how many anchors it prints. That is also why the number here is usually lower than a count of every anchor on the page.
Google's own guidance on links says it uses them as a signal when deciding how relevant pages are, and to find new pages to crawl. Both halves apply to internal links. Discovery: a page that nothing links to can still be found through a sitemap, but a page linked from your navigation and from related articles is found sooner and revisited more often. Importance: the pages you link to most, and from your strongest pages, are the ones you are telling search engines matter. Internal linking SEO is mostly the discipline of making those two signals agree with what you actually want found.
There is a third job that has nothing to do with search engines: readers. A reader who follows a link to a 404 has hit the one page on your site that cannot help them. Internal links are the only links you fully control, so they are the only broken links you have no excuse for.
The clickable words of a link tell readers and crawlers what the target is about. Google's link guidance asks for anchor text that is descriptive, reasonably concise and relevant to the page it points at. The common classes other checkers sort anchors into (LinkStorm and Zerply both do this well) are descriptive ("how depreciation recapture is taxed"), generic ("click here", "read more"), branded (your firm's name), naked (the URL itself) and empty (an image or icon with no alt text, which gives the link no words at all). Generic and empty anchors waste the one sentence the link had to say where it goes.
This checker does not report anchor text. It answers a narrower question, whether each link leads anywhere, and leaves anchor review to you or to a crawl.
A rel="nofollow" on a link asks search engines not to associate your page with the target. Google has treated it as a hint rather than a command since 2019. On links to other sites it has legitimate uses. On links to your own pages it is almost always a leftover: an old plugin setting, a template that marks every footer link nofollow, a developer's attempt to "sculpt" where equity flows. A page-level <meta name="robots" content="nofollow"> does the same thing to every link on the page at once, which SEOmator's checker points out. Neither is reported here; this tool reads where links go, not how they are marked.
Most link checkers call anything that is not a 200 an error. That is how a members-only page, a rate-limited server or a firewall that dislikes data-centre traffic ends up in a report as broken. This checker uses the rule Verand's own site crawl uses for internal links: an error code is broken, except the three codes a working page often sends to a server rather than a person. Those are held back on purpose, because a missed broken link costs less than a false alarm that sends someone rewriting a page that works.
| The link answers | This checker says | Why |
|---|---|---|
| 200 to 299 | OK | The server returned a page. The body is not read, so an error page served with a 200 (a soft 404) also passes. |
| 301, 302, 307, 308 | The final code | Redirects are followed to the end. A link that redirects to a working page is not broken; it is one extra hop worth tidying. |
| 400 to 599, except 401, 403, 429 | Broken | A 404 Not Found or 410 Gone says the page is not there; a 500 or 503 says your own server failed to serve it. On your own site, both are yours to fix. |
| 401, 403, 429 | Could not verify | A login wall, a refusal or a rate limit. Real readers may get the page; the server may simply dislike our request. |
| No answer in 6 seconds | Could not verify | A slow or unreachable server. Worth a look in a browser, not a verdict. |
/cdn-cgi/ paths | Skipped | A path Cloudflare reserves for its own features, not a page of your site. Not requested and not listed; the card says how many were skipped. |
Could not verify is not a pass. It means open the link yourself. If it loads for you, a bot wall is answering servers differently from people, which is worth knowing for its own sake, because crawlers are servers too.
We ran this checker on Willowdale Equity's privacy policy on 27 September 2026. The page carries 19 internal links; 18 were requested and all 18 answered 200. The nineteenth is a link to /cdn-cgi/l/email-protection, and the checker skipped it on purpose. That path is written by Cloudflare's Email Address Obfuscation, which replaces email addresses in the HTML with a link to that path and a hash, then decodes them with a script once the page has loaded. A visitor with JavaScript sees and clicks a normal email address. Anything that reads the served HTML without running the script sees a link to a path that answers 404.
The 404 is real, but it describes Cloudflare's endpoint, not a page of the site, and no reader ever lands on it. So the checker follows Verand's own site crawl and leaves /cdn-cgi/ out: not requested, not listed, and counted in a note on the card so nothing disappears silently. If you would rather crawlers saw the address itself, Cloudflare documents an email_off comment for exempting specific addresses; many sites keep the obfuscation as the price of hiding addresses from harvesters.
For a financial adviser, a law firm, an insurer or a medical practice, some internal links are not optional. Privacy notices, disclosure pages, fee schedules, client relationship summaries and advertising disclaimers are often expected to be reachable from the pages that mention them, and the link that does the reaching is usually in the footer. A redesign that renames /disclosures to /legal/disclosures without a redirect leaves every page on the site pointing at a 404, and nobody notices, because nobody clicks footer links while reviewing a new homepage.
That is a compliance gap, not just an SEO one. The habit that catches it takes two minutes: after any site change, run this checker on the homepage and on one service page, and confirm every disclosure link answers 200. Which pages your regulator expects, and from where, is a question for your compliance team; this tool only tells you whether the links you have lead anywhere.
A single-URL checker sees the links going out of one page. It cannot see which pages link in, so it cannot tell you that a page is an orphan (nothing links to it), how many internal links point at your most important article, or which pages are dead ends with no internal links out. Some ranking tools claim orphan detection from a single URL; it is not possible, because an orphan is defined by the pages that do not link to it. SEOmator and SEOptimer say this plainly, and so does this page.
Those questions need a crawl of the whole site. Verand's deep crawl reads every page every two weeks, builds the internal link graph, and reports orphan pages, dead ends and pages with too few contextual links pointing in. This checker is the one-page slice of that job, the part you can run on any URL in a few seconds.
Google's guidance is direct about what it can follow: generally, a link it can crawl is an anchor element with an href attribute. Mega menus, tabs, accordions and "load more" buttons built by JavaScript sometimes produce exactly that after the page loads, and sometimes produce clickable elements with no href at all. This checker reads the served HTML, before any script runs, so a link that exists only after JavaScript runs is not counted. If your navigation looks full in a browser and the count here is small, that difference is the finding: the links a crawler reads first are not the links your readers see.
staging.yourdomain.com or a preview URL copied from a CMS. Here it counts as external, because it is a different host, so look for it in the external count too.Six things that are true of this tool, each one backed by a line in the code that runs it.
The request carries a page address and nothing else. There is no account, no session and no database behind the tool, so there is nothing for us to keep about you.
Each link requested comes back with its own status code in the result, up to 50 of them. Nothing is summarised behind an email, a report or an upgrade.
Only an error code is called broken, by the same rule Verand's site crawl uses. Login walls, refusals, rate limits and timeouts are marked could not verify, so the list of links to fix is not padded with pages that work.
Links are resolved by the same function Verand's deep crawl uses to check outbound links and citations on customer sites, with the same HEAD-then-GET fallback and the same conservative rule.
The 50-link cap, JavaScript-built links, anchor text, nofollow and orphan pages are all stated beside the result, including exactly how many links were counted but not requested.
A run is a page fetch and a few dozen small requests, so it costs nothing and is never metered. The one limit is a courtesy to the sites being fetched: 20 checks a minute per visitor.
What it checks, what it calls broken, and what it cannot tell you from one page.
This one fetches the page you enter, counts its internal and external links (each path once), and requests up to 50 of the internal links, reporting the status code each one answers. A link is marked broken on any 4xx or 5xx answer except 401, 403 and 429; those, and a timeout, are marked could not verify. Links to Cloudflare's /cdn-cgi/ paths are skipped. It works as a free broken link checker for one page's internal links. External links are counted but not requested, and anchor text and nofollow are not reported.
Our server requests the page as VerandBot, follows any redirects and reads the HTML it is sent. Every anchor with an href is resolved against the page and sorted into internal or external. The first 50 unique internal links in source order, leaving out /cdn-cgi/ paths, are then requested eight at a time: a HEAD request, retried as a GET when the server refuses HEAD, answers 403 or does not answer, with redirects followed and six seconds per request. Nothing runs in a browser and nothing is written to your site.
A link is internal when it resolves to the same host as the page, with www and the bare domain treated as one site, so /fees and https://www.yourdomain.com/fees are the same internal link. A subdomain such as blog.yourdomain.com or app.yourdomain.com is a different host and counts as external. Mail, phone and javascript links and jump links to a #section are skipped. Query strings and fragments are dropped from internal links, so each page is counted once.
No. The checker follows redirects to the end and reports the final answer, so a link that redirects to a working page shows 200 and reads as fine. It is still worth updating, because every internal link that passes through a redirect is a hop you control and could remove. This tool does not show the hops themselves; the Redirect Checker shows each one with its status code. A redirect that ends on a 404 is reported as broken.
There is no official number, and figures quoted by tool vendors come from their own samples. A useful test is whether each link helps a reader of that page: navigation to your main sections, links from the body to the pages that explain terms or services it mentions, and the footer pages people expect. A long article linking to nothing else on your site is a missed chance; a page whose links are mostly repeated navigation says little about what matters. Remember the count here is from the served HTML, so JavaScript-built menus are not in it.
A rel="nofollow" asks search engines not to associate your page with the one it links to, and Google has treated it as a hint since 2019. On links to your own pages that is rarely what you want: it withholds the signal you built the link to send. It usually arrives as a template or plugin default, or from a page-level meta robots nofollow that applies to every link at once. This checker does not read rel attributes, so check your templates directly if you suspect it.
A page with no dead ends is the floor, not the goal. Verand writes articles from your own expertise and credentials, so both Google and the AI assistants have something of yours to name. It then tracks where you rank and where ChatGPT, Gemini, Perplexity, Claude and Google's AI answers mention you, and gates every draft so a claim your regulator would not allow never publishes.
Content built to rank in
Google and get cited by
ChatGPT
Perplexity
Gemini
Claude, with every claim checked before it goes live.