Link problems accumulate quietly. A page gets renamed and three older articles still point at the old address. An HTTPS migration leaves a handful of images loading over HTTP. A site you linked to five years ago now redirects somewhere unrelated.
None of this announces itself. Crawling tools will find it, and they are worth having for a large site, but for a page or a section you can do the same work manually in about ten minutes.
Getting the links out of a page
View the source of the page — Ctrl+U in most browsers, or Cmd+Option+U on a Mac — select all, and copy.
Paste that into our URL Extractor and you get every absolute link on the page as a list. Turn on unique and sort, and the shape of the page's linking becomes obvious immediately.
One limitation to know about: relative links written as /about or //example.com/page are not extracted, because they are not complete addresses. If your templates use relative paths internally, you will see only the absolute ones. Viewing the rendered DOM through developer tools rather than the raw source gives you resolved absolute URLs in many cases.
Audit one: internal linking
Type your own domain into the domain filter. What remains is the page's internal link structure, without the noise of social buttons and external references.
What you are looking for:
How many are there? A substantial article with two internal links is under-linked. Internal links distribute authority through your site and give readers somewhere to go next. There is no correct number, but a long page with almost none is a missed opportunity.
Are they the same three pages every time? A common pattern is every article linking to the home page and the contact page and nothing else. That does nothing for the pages that need help.
Do any point at old addresses? If you have renamed pages, the redirects may be doing the work silently. Redirects are fine but they cost a round trip and they can chain. Updating the link to point at the final destination is better.
Audit two: mixed content
This one has a specific and visible symptom — the padlock disappearing, or resources failing to load after a migration to HTTPS.
Filter the extracted list to HTTP only. Anything that comes back is an insecure link on a secure page. Browsers block insecure scripts, stylesheets and iframes outright, and flag insecure images.
The usual survivors of a migration are hard-coded image paths in old article content, embedded widgets from third parties, and links in templates that were written before the certificate was installed. The first category is the most common, and it lives in your database rather than your templates, which is why it survives a theme update.
Audit three: outbound links
Now invert the filter and look at what leaves your site.
Where do they go? Sites disappear, get sold and change purpose. A five-year-old article linking to a resource that is now a gambling site is a genuine problem, and nobody will tell you about it.
Are the important ones still alive? Feed the external list into a link checker to find the dead ones. Keeping the extraction and the checking as separate steps is what allows the extraction itself to run entirely in your browser.
Is anything unintended? Sometimes a plugin, an embed or an old advertisement is adding links you did not put there.
Sitemap comparison
A useful variant. Fetch your sitemap.xml and extract every URL from it. Do the same for last month's copy if you have one, or for the sitemap of a competitor.
Paste both lists together into the Duplicate Line Remover with duplicates-only mode on, and what comes back is the overlap. Run it in normal mode and the unique entries tell you what was added or removed.
This is the quickest way to answer "what changed?" after a migration, and to spot pages that vanished from the sitemap without anyone noticing.
What this approach does not replace
Being honest about the limits: this is page-by-page. It will not crawl your whole site, follow redirect chains, test response codes, or find orphaned pages that nothing links to. For a site of a few hundred pages you want a proper crawler.
What it is good for is targeted work. Auditing the twenty pages that matter most. Checking a template change before it goes live. Diagnosing a specific mixed-content warning. Comparing two sitemaps. Those are the jobs where opening a crawler is more effort than the task deserves.
A ten-minute routine
- Copy the page source
- Extract all URLs, unique and sorted
- Filter to your domain — check internal linking depth and old addresses
- Filter to HTTP only — anything here is mixed content
- Look at the external list — check for dead or repurposed destinations
- Repeat for your top pages, then quarterly
