Onsite Link Verdict checks the links and images in your posts, pages and comments and tells you which ones are dead.<\/p>\n\n
This distinction is the whole reason this plugin exists.<\/p>\n\n
Plenty of servers refuse automated requests. Amazon answers So Onsite Link Verdict only ever calls a link broken when it has proof:<\/p>\n\n Everything else goes to a separate \"Unverifiable\" tab<\/strong>, with a plain-language note about what happened. If a server answered us \u2014 with There is no account to create, no cloud service and no credit card. Your posts, pages and comments are not uploaded anywhere \u2014 see \"External services\" below for everything that does leave your site, and why.<\/p>\n\n Checking links is real work for the same server that answers your readers. Onsite Link Verdict is built around that:<\/p>\n\n The link scanner runs locally, on your own site's cron, on the same server that answers your readers. There is no cloud service behind the plugin, no API key and no account to create: the results live in a table in your own database, and your content is never uploaded anywhere.<\/p>\n\n Some things do go out of your site \u2014 the servers hosting the links being checked, and Freemius, which runs our licensing and checkout. They are set out one by one, with the domains and with what you can decline, under \"External services\" below.<\/strong><\/p>\n\n What that buys you:<\/p>\n\n The privacy note for the plugin is at https:\/\/onsitetools.dev\/privacy\/ and says the same thing in more detail.<\/p>\n\n Once the first sweep is done it keeps monitoring. Every link is checked again after a week, and one that is failing after a day, so a page that dies next month turns up next month \u2014 you do not have to remember to run an audit.<\/p>\n\n Onsite Link Verdict finds<\/strong> broken links and tells you exactly which post, page or comment each one is in. It does not edit your content: you fix each link in the editor, where you can see it in context.<\/p>\n\n That is deliberate. Where a link should point is a judgement about your content, and the editor is where you can see the sentence it sits in.<\/p>\n\n Replacing one URL across an entire site in a single step is the obvious next thing to want. That is what Pro is for, below.<\/p>\n\n Everything above is free, and stays free. Pro does the mechanical part, for people with more than a handful of links to fix:<\/p>\n\n Pro is an annual licence, from 29 EUR a year plus VAT, for one site. It is bought from https:\/\/onsitetools.dev\/onsite-link-verdict\/ and there is a link inside the plugin. The free version never asks you for an email address of its own: the only place an email is shared is the activation opt-in described above, which you can decline.<\/p>\n\n This plugin contacts two external destinations: the websites you link to, and Freemius, which\nhandles our licensing and payments. Here is what goes to each, and when.<\/p>\n\n Checking whether a link is alive means requesting it from the server that hosts it. That server\nreceives the address being checked and, in the Links to your own site are requested the same way, over HTTP, from your own server. When one of\nthose answers Freemius Inc. runs our licensing, updates and checkout. It is contacted in four situations, and\nonly the first is optional.<\/p>\n\n On activation, if you opt in.<\/strong> WordPress shows you a screen asking whether to share information\nabout your site. There are four groups, and you can clear all but the first:<\/p>\n\n You can decline the whole screen<\/strong>, and the plugin works exactly the same \u2014 declining is handled\nentirely inside your own site and sends nothing.<\/p>\n\n On a schedule, if you opted in.<\/strong> Your site then checks in with Freemius periodically to see\nwhether a licence has been bought or changed. This happens in the free version too, and needs no\nlicence key.<\/p>\n\n When you open the \"Change Plan\" screen<\/strong> inside WordPress. That screen loads the current prices\nfrom Freemius when you open it, whether or not you opted in.<\/p>\n\n When you deactivate the plugin.<\/strong> WordPress shows a short form asking why; if you fill it in, the\nreason goes to Freemius. Closing it sends nothing.<\/p>\n\n And, in the paid add-on only, your licence key is validated with the same service.<\/p>\n\n Domains contacted: No other destination is contacted. Your posts, pages and comments are not uploaded anywhere, and\nthe result of every check is stored in a table in your own database.<\/p>\n\n\n No. Your posts, pages and comments stay where they are, and the results are stored in your own database. There is no cloud service behind the plugin holding your content. See \"External services\" below for everything that does go out, and why.<\/p><\/dd>\n It reads your posts, pages and comments and stores the links it finds in a table in your own database. Your content is not uploaded, and there is no cloud service behind it.<\/p>\n\n Two destinations are contacted, and both are set out in full under \"External services\" above: the servers that host the links being checked, and Freemius, which runs our licensing and checkout. The Freemius contact starts with an opt-in screen you can decline.<\/p>\n\n What that means for your own processing records is for you to decide \u2014 this is a description of the plugin, not legal advice.<\/p><\/dd>\n It is built not to. Work happens in small scheduled batches with a hard cap, not all at once.<\/p><\/dd>\n No. It finds them and tells you exactly where each one is; you change the link in the post editor, where you can see it in context. Replacing a URL across the whole site in one step \u2014 with a preview of every change before it happens, and an undo \u2014 is what the paid add-on does.<\/p><\/dd>\n Because the server answered us with something that is not They are kept separate on purpose. A refusal is not a death: the page is there, and a reader with a browser reaches it. Nor is it something you can fix from your own site, since what a distant server does with an automated request is not yours to configure.<\/p><\/dd>\n Because it deliberately works in small bites in the background. How long depends on how many links you have and which speed you picked: the panel shows the estimate for your own site next to each setting, under Tools \u2192 Onsite Link Verdict.<\/p>\n\n If it is slower than you want, change the setting to Fast \u2014 but read what it says there first. Checking faster means hammering the sites you link to harder, and more of them will start refusing the checks, which puts those links in \"Couldn't verify\" instead of giving you a real answer.<\/p><\/dd>\n They leave the list as each post is checked again, not all at once. A rule takes effect the next time Onsite Link Verdict scans the post, page or comment a link sits in \u2014 so on a small site they disappear quickly, and on a site with hundreds of posts a full sweep takes several background runs. Nothing is stuck; the list is catching up.<\/p>\n\n If you want a rule to take effect on one specific post right away, open that post and save it. That schedules a fresh scan of it.<\/p>\n\n (Exclusion rules are part of Pro.)<\/p><\/dd>\n Your site's cron is probably disabled. Onsite Link Verdict shows a warning at the top of its page when it detects this. Ask your host how to set up a real cron job.<\/p><\/dd>\n\n<\/dl>\n\n\n503<\/code> to bots. X answers 403<\/code>. LinkedIn answers 999<\/code>. A site behind a firewall throws a challenge page. None of those links are broken<\/strong> \u2014 they open perfectly well in your browser. Report them as broken and you hand the user a list of two hundred problems, of which one hundred and ninety are not problems, and they stop trusting the list.<\/p>\n\n\n
404<\/code> or 410<\/code>. And even then we ask a second time, with a different method, before accusing the link: there are servers that answer 404<\/code> to one kind of request and 200<\/code> to another, and a wrong accusation here is the most expensive kind.<\/li>\n403<\/code>, 503<\/code>, a rate limit, a challenge page, anything that is not 404<\/code> or 410<\/code> \u2014 it answered, and that is not proof the page died. Your list of real problems stays short, and short means believable.<\/p>\n\nIt runs on your own server, and stays out of the way<\/h4>\n\n
\n
HEAD<\/code> requests first, falling back to GET<\/code> only when a verdict depends on it. At most 2 KB of any response body is ever read.<\/li>\nWhat it checks<\/h4>\n\n
\n
A local broken link checker: no cloud service, no credits<\/h4>\n\n
\n
What you get<\/h4>\n\n
\n
404<\/code> \u2014 and instead of telling you the page no longer exists, Onsite Link Verdict tells you it exists and is not published, and which status it is in<\/li>\nWhat it does not do<\/h4>\n\n
Onsite Link Verdict Pro<\/h4>\n\n
\n
External services<\/h3>\n\n
1. The websites you link to<\/h4>\n\n
User-Agent<\/code> header that identifies the checker,\nyour site's address and the plugin's version. This happens for every link in your content, on the\nplugin's own schedule. It is what the plugin is for, and it cannot be switched off without\nswitching off the checking.<\/p>\n\n404<\/code> or 410<\/code>, the plugin then looks the address up in your own database, so it can\ntell you the page exists but is a draft, private or pending, instead of reporting it gone.<\/p>\n\n2. Freemius<\/h4>\n\n
\n
api.freemius.com<\/code>, wp.freemius.com<\/code>, checkout.freemius.com<\/code>.\nFreemius terms: https:\/\/freemius.com\/terms\/ \u00b7 Freemius privacy: https:\/\/freemius.com\/privacy\/<\/p>\n\nNothing else<\/h4>\n\n
\n
\n
Does this send my content anywhere?<\/h3><\/dt>\n
What data does the plugin handle?<\/h3><\/dt>\n
Will it slow my site down?<\/h3><\/dt>\n
Can it fix the broken links for me?<\/h3><\/dt>\n
Why is a link listed as \"Unverifiable\"?<\/h3><\/dt>\n
404<\/code> or 410<\/code>. Some servers refuse automated requests \u2014 Amazon, X, LinkedIn and anything behind a bot firewall all do. The link is probably fine; open it in your browser to confirm.<\/p>\n\nWhy is it taking so long to check my links?<\/h3><\/dt>\n
I added an exclusion rule and the links are still in the list<\/h3><\/dt>\n
The plugin never seems to check anything<\/h3><\/dt>\n
0.6.6<\/h4>\n\n
\n
0.6.5<\/h4>\n\n
\n
0.6.4<\/h4>\n\n
\n
0.6.3<\/h4>\n\n
\n
0.6.2<\/h4>\n\n
\n
0.6.1<\/h4>\n\n
\n
0.6.0<\/h4>\n\n
\n
0.5.2<\/h4>\n\n
\n
0.5.1<\/h4>\n\n
\n
0.5.0<\/h4>\n\n
\n
0.3.0<\/h4>\n\n
\n
the_content<\/code> and need to know which post they are drawing, which they ask the global $post<\/code>. Onsite Link Verdict was not setting it up, so on a page built with Elementor \u2014 where the post content itself is empty \u2014 the scan found nothing<\/strong> and reported a clean bill of health. A false all-clear is worse than a false positive: with a false positive you lose time, with this you lose the page and never know. Verified against a real Elementor install.<\/li>\n<\/ul>\n\n0.2.0<\/h4>\n\n
\n
HEAD<\/code> request alone. Some servers answer 404<\/code> to HEAD<\/code> and 200<\/code> to GET<\/code> \u2014 zazzle.com does exactly this \u2014 and a 404<\/code> is the one verdict Onsite Link Verdict gives immediately, with no second chance. Every 404<\/code> and 410<\/code> is now confirmed with a GET<\/code> before the link is accused. Healthy links still cost a single request.<\/li>\n404<\/code>, 410<\/code> and a total absence of response now count as proof. This fixes the case where a site that persistently answers 503<\/code> to bots \u2014 Amazon does exactly this \u2014 was reported as a broken link after three checks.<\/li>\nCF-Mitigated<\/code>, CF-Chl-Bypass<\/code>, X-DataDome<\/code>, Retry-After<\/code>) and go straight to Unverifiable, whatever status code they carry.<\/li>\n0.1.0<\/h4>\n\n
\n