DEV Community: linkbruno.com

How to find mixed content (http:// links) on an HTTPS site

linkbruno.com — Sat, 31 Oct 2026 22:39:36 +0000

Your site moved to HTTPS years ago, but the old http:// URLs are still in there: in blog posts, in image tags, in a footer someone hard-coded. Some of them cause browser warnings, some get blocked outright, and some just add a redirect hop. Here's how to find them and what to do with each kind.

Two kinds of mixed content

Active mixed content is anything that can change the page: scripts, stylesheets, iframes, fetch requests. Browsers block these on HTTPS pages, so a script loaded over http:// simply doesn't run. The result is a broken feature with no visible error.

Passive mixed content is images, audio and video. Modern browsers try to upgrade these to HTTPS automatically. If the HTTPS version doesn't exist, the image breaks.

Plain <a href="http://..."> links aren't mixed content (they're navigation), but on your own domain they still trigger an extra redirect for every click, and on other domains they may point to sites that no longer serve HTTP at all.

Find it in the browser

Open DevTools, then the Console. Mixed content shows up as warnings like:

Mixed Content: The page at 'https://example.com/' was loaded over HTTPS,
but requested an insecure image 'http://example.com/img/logo.png'.

Good for one page; not practical for a whole site.

Find it with grep in your source

If your content is in files:

grep -rnoE 'http://[^"'"'"' )>]+' --include='*.html' --include='*.md' --include='*.php' . \
  | grep -v 'http://www.w3.org' | sort | uniq

The w3.org filter removes XML namespace strings, which look like URLs but aren't requests.

Find it in a WordPress database

Old posts store absolute URLs in the content:

SELECT ID, post_title
FROM wp_posts
WHERE post_status = 'publish'
  AND post_content LIKE '%src="http://%';

To replace your own domain safely, use WP-CLI, which handles serialized data correctly:

wp search-replace 'http://example.com' 'https://example.com' --dry-run
wp search-replace 'http://example.com' 'https://example.com'

Always run the dry run first and take a database backup.

Crawl the rendered pages

Source searches miss URLs built by templates, plugins and themes. A small crawler over the rendered HTML catches those:

import requests, re
from urllib.parse import urljoin

def insecure_resources(url):
    html = requests.get(url, timeout=15, headers={"User-Agent": "Mozilla/5.0"}).text
    found = set()
    for attr, val in re.findall(r'(src|href|srcset|data-src)=["\']([^"\']+)', html):
        for part in val.split(","):
            u = part.strip().split(" ")[0]
            if u.startswith("http://"):
                found.add((attr, u))
    return found

for page in ["https://example.com/", "https://example.com/blog/"]:
    for attr, u in insecure_resources(page):
        print(page, attr, u)

Feed it the URLs from your sitemap to cover every page.

What to do with each finding

Finding	Action
Your own domain over http	Change to https (or a root-relative path)
Third-party resource that supports https	Change to https
Third-party resource with no https	Host it yourself, replace it, or remove it
Plain link to an external http site	Check it still works; update to https if available

Don't switch to protocol-relative URLs (//example.com/...). They were a workaround for the HTTP era and just add ambiguity now.

Add a safety net

The upgrade-insecure-requests directive tells browsers to fetch every http:// resource over HTTPS:

Content-Security-Policy: upgrade-insecure-requests

It hides the warnings, but if the HTTPS version of a resource doesn't exist, it still breaks. Use it as a backstop, not a fix.

Keep it fixed

New mixed content comes back with every pasted embed and copied snippet. A scheduled crawl that checks every link and image on the site catches regressions; linkbruno.com is built for that kind of ongoing check, alerting when a link or image breaks.

Check links in Markdown docs with a 60-line Python script

linkbruno.com — Sat, 31 Oct 2026 22:39:12 +0000

Documentation rots quietly. A README links to a blog post that moved, a docs page points to an API reference that was renamed, and nobody notices until a reader complains. If your docs live in Markdown, you can catch most of this with a short Python script that runs locally or in CI.

What the script does

Finds every .md file in a folder
Pulls out inline links [text](url) and bare <https://...> links
Checks relative links against the file system
Checks external links with an HTTP request
Prints a report and exits non-zero if anything is broken

The code

#!/usr/bin/env python3
import re, sys, pathlib, concurrent.futures as cf
import requests

LINK_RE = re.compile(r'\[[^\]]*\]\(([^)\s]+)(?:\s+"[^"]*")?\)|<(https?://[^>]+)>')
HEADERS = {"User-Agent": "Mozilla/5.0 (docs link check)"}
SKIP = ("mailto:", "tel:", "#")

def links_in(path):
    text = path.read_text(encoding="utf-8")
    # ignore fenced code blocks
    text = re.sub(r"```

.*?

```", "", text, flags=re.S)
    for m in LINK_RE.finditer(text):
        yield m.group(1) or m.group(2)

def check_url(url):
    try:
        r = requests.head(url, headers=HEADERS, allow_redirects=True, timeout=10)
        if r.status_code in (403, 405) or r.status_code >= 500:
            r = requests.get(url, headers=HEADERS, allow_redirects=True, timeout=15, stream=True)
        return url, r.status_code
    except requests.RequestException as e:
        return url, type(e).__name__

def main(root):
    root = pathlib.Path(root)
    external, problems = {}, []
    for md in root.rglob("*.md"):
        for link in links_in(md):
            if link.startswith(SKIP):
                continue
            if link.startswith(("http://", "https://")):
                external.setdefault(link, []).append(md)
            else:
                target = (md.parent / link.split("#")[0]).resolve()
                if not target.exists():
                    problems.append((md, link, "missing file"))
    with cf.ThreadPoolExecutor(max_workers=8) as pool:
        for url, status in pool.map(check_url, external):
            if status != 200 and not (isinstance(status, int) and status < 400):
                for md in external[url]:
                    problems.append((md, url, status))
    for md, link, why in problems:
        print(f"{md}: {link} -> {why}")
    return 1 if problems else 0

if __name__ == "__main__":
    sys.exit(main(sys.argv[1] if len(sys.argv) > 1 else "."))

Run it:

pip install requests
python3 check_md_links.py docs/

Why HEAD first, then GET

A HEAD request asks for headers only, which is fast and light on the remote server. Some servers don't support it properly and answer 405 or 403, or even 500, to a HEAD while a normal GET works. Falling back to GET for those codes removes most false alarms. stream=True means the body isn't downloaded.

Relative links matter too

Most broken links in docs aren't external. They're relative links to a file that got renamed: [setup](../install.md) after install.md became installation.md. The script resolves each relative path from the file that contains it and checks it exists. It strips #section anchors first; checking that the heading still exists is a good next step if you need it.

Running it in CI

A GitHub Actions job:

name: docs-links
on:
  pull_request:
    paths: ["docs/**", "README.md"]
  schedule:
    - cron: "0 6 * * 1"
jobs:
  links:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: { python-version: "3.12" }
      - run: pip install requests
      - run: python3 check_md_links.py docs/

The pull request trigger catches broken relative links before they merge. The weekly schedule catches external links that broke on their own, which no pull request would ever reveal.

Handling flaky results

External checks will occasionally fail for reasons that have nothing to do with your docs: rate limits (429), sites that block unknown clients, short outages. Some practical rules:

Treat 429 and timeouts as warnings, not failures, on pull requests
Keep an allowlist for domains that always block automated requests
Re-check failures once before reporting them

Where this stops

This covers the Markdown source. It doesn't see links generated by templates, navigation menus, or anything rendered by JavaScript after the site builds. For a published docs site, checking the built HTML pages on a schedule catches those too. That's what linkbruno.com does for whole websites: it crawls on a schedule, checks every link and image, and alerts by email or Slack when one breaks.

How to find broken outbound links and replace them (using the Wayback Machine)

linkbruno.com — Wed, 28 Oct 2026 15:37:59 +0000

Your own pages stay where you put them. The pages you link to don't. Other sites redesign, move their docs, shut down or let their domain expire, and every link from your content to them slowly goes bad.

Outbound link rot hurts in two ways. Readers hit dead ends in the middle of your article, and some "working" links quietly point somewhere you'd never recommend, like a parked domain full of ads. Here's how to find those links and what to replace them with.

The three ways outbound links fail

Hard failures. 404, 410, DNS errors, connection refused. Easy to detect.
Redirects to somewhere else. The old URL now redirects to the homepage or a generic landing page. It returns 200, but the content you cited is gone. This is a soft 404.
Expired domains. The site's owner let the domain lapse and someone else bought it. It now shows a "this domain may be for sale" page, ads, or worse. Also 200 OK.

Only the first kind shows up in a simple status check. The other two need you to look at where the link ends up.

Step 1: List every outbound link

Start with your sitemap so you check real pages, then collect every link that leaves your domain. This script prints each external URL with the page it's on:

import re
from html.parser import HTMLParser
from urllib.parse import urljoin, urlparse

import requests

SITE = "https://example.com"
HOST = urlparse(SITE).netloc

class Links(HTMLParser):
    def __init__(self):
        super().__init__()
        self.hrefs = []
    def handle_starttag(self, tag, attrs):
        if tag == "a":
            href = dict(attrs).get("href")
            if href:
                self.hrefs.append(href)

sitemap = requests.get(f"{SITE}/sitemap.xml", timeout=15).text
pages = re.findall(r"<loc>(.*?)</loc>", sitemap)

outbound = {}
for page in pages:
    p = Links()
    p.feed(requests.get(page, timeout=15).text)
    for href in p.hrefs:
        url = urljoin(page, href).split("#")[0]
        host = urlparse(url).netloc
        if url.startswith("http") and host and host != HOST:
            outbound.setdefault(url, set()).add(page)

for url, found_on in sorted(outbound.items()):
    print(url, "|", ", ".join(sorted(found_on)))

If your sitemap is an index of other sitemaps, fetch those first. For a site with thousands of pages, cap pages while you test.

Step 2: Check each link and record where it ends up

Request each URL, follow redirects, and keep both the status and the final address:

import time

def check(url):
    try:
        r = requests.get(url, timeout=20, allow_redirects=True, stream=True,
                         headers={"User-Agent": "Mozilla/5.0 (outbound link audit)"})
        r.close()
        return r.status_code, r.url
    except requests.RequestException as e:
        return 0, type(e).__name__

for url in outbound:
    status, final = check(url)
    moved_host = urlparse(final).netloc not in ("", urlparse(url).netloc)
    went_home = urlparse(final).path in ("", "/") and urlparse(url).path not in ("", "/")
    if status == 0 or status >= 400 or moved_host or went_home:
        print(status, url, "->", final)
    time.sleep(1)

The time.sleep(1) keeps you from hammering any one site. The output flags:

errors and unreachable hosts
links that now land on a different domain, a common sign of an expired or sold domain
links that now land on the homepage, a common sign the specific page was removed

Ignore 403, 429 and LinkedIn's 999 for now. Those usually mean the site blocks scripts, not that the page is gone. Open them in a browser.

Step 3: Look at the suspicious ones

For links that moved to a different domain or the homepage, open them and decide:

Is this the same organisation under a new name? Then the redirect is fine, but update the link to the final URL.
Is it a parked page, a domain marketplace, or unrelated content? Remove or replace the link now. Keeping it sends readers somewhere you don't control.

Step 4: Find a replacement

When the page you cited is gone, you have three options, in order of preference.

1. Find where it moved. Search the original site for the page title, or search the web for the exact title in quotes. Docs and blog posts often survive a redesign under a new URL.

2. Link to an archived copy. The Wayback Machine at the Internet Archive keeps snapshots of a huge number of pages. Its availability API returns the closest snapshot for a URL:

curl -s "https://archive.org/wayback/available?url=example.org/old-guide"

{"archived_snapshots": {"closest": {"available": true, "status": "200",
  "url": "http://web.archive.org/web/20230115000000/https://example.org/old-guide",
  "timestamp": "20230115000000"}}}

In Python:

def wayback(url):
    r = requests.get("https://archive.org/wayback/available", params={"url": url}, timeout=20)
    snap = r.json().get("archived_snapshots", {}).get("closest")
    return snap["url"] if snap and snap.get("available") else None

Open the snapshot before you use it. Check that it shows the actual content you cited, not an error page that was archived after the site broke. Adding a timestamp parameter (&timestamp=20220101) asks for the snapshot closest to that date, which helps you get a copy from when you first linked.

3. Replace the source. If neither works, cite a different page that makes the same point, or rewrite the sentence so it doesn't need a link.

Step 5: Update links in bulk

Most outbound link rot clusters around a few domains. If one docs site moved everything from /docs/ to /documentation/, a single search and replace in your CMS or repository fixes dozens of links at once. Sort your results by domain before you start editing.

In a static site repo:

grep -rl "olddocs.example.org" content/ | xargs sed -i 's#https://olddocs.example.org/#https://docs.example.org/#g'

Review the diff before you commit.

Keep it from piling up again

Outbound links break on other people's schedules, so a one-off audit goes stale quickly. Rerun the scripts above every few months, or use a monitor that does it for you. linkbruno.com, for example, checks external links on a schedule, flags parked and expired domains, and shows the Wayback Machine's last copy of dead pages so the replacement is one click away.

Either way, a few minutes of upkeep keeps your older articles useful, and your readers never land on a domain-for-sale page from a link you recommended.

Anchor link not working? How to find and fix broken #section links

linkbruno.com — Wed, 28 Oct 2026 15:32:13 +0000

You click a link like /docs/setup#install and the page loads, but it stays at the top. No error, no 404. The link is broken in a way most tools never notice, because the page itself returns 200 OK.

These broken anchor links are common in documentation, long guides and tables of contents. Here's why they happen, how to debug one, and how to find every broken anchor on a site.

How anchor links work

The part after # is called a fragment. Your browser never sends it to the server. It loads the page, then looks for an element whose id matches the fragment and scrolls to it:

<a href="/docs/setup#install">Install</a>

<!-- on /docs/setup -->
<h2 id="install">Install</h2>

If no element has id="install", the browser simply doesn't scroll. That's the whole failure, and it's silent.

Why anchor links break

The heading was renamed. Many CMSs and static site generators create ids from heading text. Rename "Install" to "Installation" and the id changes from install to installation. Every link to the old one stops working.

The generator changed. Switching Markdown renderers or upgrading one can change how ids are built: getting-started, getting_started or gettingstarted. A site migration can break hundreds of anchors at once.

Case doesn't match. Fragments are case-sensitive. #Install won't match id="install".

Special characters. A heading like "What's new in v2.0?" becomes something unpredictable. Spaces turn into %20 in some links and - in others.

Duplicate ids. If two elements share an id, the browser jumps to the first one, which may not be the one you meant.

Content loads later. If the target is rendered by JavaScript after page load, the browser may look for the id before it exists.

It works, but the header hides it. The page does scroll, but a sticky header covers the heading, so it looks like the link went to the wrong place.

Debug one broken anchor

Open the target page, then the browser console, and check the id directly:

document.getElementById('install');           // null means it doesn't exist
document.querySelectorAll('[id="install"]').length;   // more than 1 means duplicates

If it returns null, find what the id is now:

[...document.querySelectorAll('h1[id],h2[id],h3[id],h4[id]')]
  .map((h) => `${h.id}  ${h.textContent.trim()}`)
  .join('\n');

That lists every heading id on the page. Update the link to match, or add the old id back (see below).

Fix the sticky header problem

If the browser scrolls but the heading ends up under a fixed header, add a scroll margin:

:target,
h2[id], h3[id] {
  scroll-margin-top: 80px; /* height of your header plus a little space */
}

No JavaScript needed. This works in all current browsers.

Find every broken anchor on a site

Regular link checkers strip the fragment and only check that the page loads, so they report these links as fine. You need a check that also reads the target page and looks for the id. Here's a small Python script that does that for a list of pages:

import sys
from html.parser import HTMLParser
from urllib.parse import urljoin, urldefrag, unquote

import requests

class Collector(HTMLParser):
    def __init__(self):
        super().__init__()
        self.ids, self.links = set(), []
    def handle_starttag(self, tag, attrs):
        a = dict(attrs)
        for key in ("id", "name"):
            if a.get(key):
                self.ids.add(a[key])
        if tag == "a" and a.get("href"):
            self.links.append(a["href"])

cache = {}
def parse(url):
    if url not in cache:
        p = Collector()
        p.feed(requests.get(url, timeout=15).text)
        cache[url] = p
    return cache[url]

for page in sys.argv[1:]:
    for href in parse(page).links:
        target, frag = urldefrag(urljoin(page, href))
        if not frag or frag == "top" or not target.startswith("http"):
            continue
        if unquote(frag) not in parse(target).ids:
            print(f"MISSING #{frag}  on {target}  (linked from {page})")

Run it with the pages you care about:

pip install requests
python anchors.py https://example.com/docs/ https://example.com/docs/setup

It caches each page so a target linked from many places is fetched once. It also accepts the old name attribute, which browsers still honour for <a name="...">.

Two limits: it reads the HTML the server sends, so ids added by JavaScript won't be found, and it ignores # and #top, which are special cases.

For a whole site, a broken link checker that understands fragments saves you writing the crawler. linkbruno.com reports missing #section anchors alongside 404s and redirect problems.

Make anchors stable

The best fix is to stop ids from changing when headings change.

Set ids explicitly. Most Markdown tools support custom heading ids:

## Installation {#install}

That works in many static site generators and Markdown extensions. Check your renderer's docs for the exact syntax.

Keep the old id when you rename. If you can't use custom ids, add an empty element with the old id next to the heading:

<span id="install"></span>
<h2 id="installation">Installation</h2>

Keep ids short and lowercase. #install survives more edits than #how-to-install-the-cli-on-windows-10.

Avoid duplicates. If you reuse components on one page, prefix their ids.

When the target is rendered by JavaScript

If your page builds its content after load, the browser's built-in jump can fire too early. Scroll manually once the content is ready:

function scrollToHash() {
  const el = location.hash && document.getElementById(decodeURIComponent(location.hash.slice(1)));
  if (el) el.scrollIntoView();
}
// call after your content has rendered
renderContent().then(scrollToHash);

Most frameworks with client-side routing have a setting for this, so check yours before adding custom code.

Summary

Broken anchor links return 200, so they hide from status checks. Look up the id in the console to debug one, add scroll-margin-top if a sticky header is in the way, give important headings explicit ids, and check fragments, not just pages, whenever you audit your links.

How to find and fix broken images on a website

linkbruno.com — Wed, 28 Oct 2026 15:26:17 +0000

A broken image is easy to miss. On some pages it shows as a small icon with alt text, on others it leaves a blank gap, and if it's a CSS background you might see nothing at all. Visitors notice, though, and so do search engines when your product photos or diagrams return 404.

Here's why images break, how to find every broken one on a page or a site, and how to fix them so they stay fixed.

Why images break

Almost every broken image comes from one of these:

Case-sensitive paths. Photo.JPG and photo.jpg are the same file on macOS and Windows, but different files on a Linux server. An image that works locally can 404 in production.
Relative paths that moved. img/logo.png on /about means /about/img/logo.png, not /img/logo.png. Moving a page to a deeper URL silently breaks it.
Deleted uploads. Someone cleans up the media library or a CDN bucket, and old posts still reference the files.
Hotlinked images. You embedded an image from another site. They renamed it, removed it, or started blocking requests from other domains.
A migration. The domain or folder structure changed, and the image URLs inside old content didn't.
Only some sizes are broken. A srcset lists five widths and one of them is missing. Most desktop browsers look fine, but some phones get the broken one.

Find broken images on one page

DevTools Network tab

Open the page, press F12, go to Network, choose the Img filter and reload. Click the Status column header to sort. Anything 404, 403 or 5xx is a problem. This also catches CSS background images and images loaded by JavaScript, because the browser actually requested them.

Try a narrow window too, or switch on device emulation, so the browser requests the smaller srcset candidates.

A console snippet

For <img> tags, the browser already knows which ones failed. An image that finished loading with a width of zero didn't decode:

const broken = [...document.images].filter(
  (img) => img.complete && img.naturalWidth === 0
);
console.table(broken.map((img) => ({ src: img.currentSrc || img.src, alt: img.alt })));

Scroll to the bottom of the page first. Lazy-loaded images (loading="lazy") aren't requested until they are near the viewport, so they won't show up as failed yet.

Check every srcset candidate

The browser only fetches one candidate per image. To test all of them, collect the URLs and request each one:

const urls = new Set();
document.querySelectorAll('img[src], img[srcset], source[srcset]').forEach((el) => {
  if (el.src) urls.add(el.src);
  (el.srcset || '').split(',').forEach((part) => {
    const u = part.trim().split(/\s+/)[0];
    if (u) urls.add(new URL(u, location.href).href);
  });
});

for (const url of urls) {
  const res = await fetch(url, { method: 'HEAD' }).catch(() => null);
  if (!res || !res.ok) console.warn(res ? res.status : 'failed', url);
}

Cross-origin images may fail this check because of CORS even when they load fine. Verify those with curl.

Check images from the command line

curl is the most reliable way to see what the server actually returns:

curl -sI https://example.com/images/hero.webp | head -n 5

Look at two things: the status line, and content-type. A 200 with content-type: text/html means the server returned an HTML page (often a "not found" template) instead of an image. That's a broken image that a status-only check would pass.

To test a list of image URLs at once:

while read -r url; do
  curl -s -o /dev/null -w '%{http_code} %{content_type}  '"$url"'\n' "$url"
done < images.txt | grep -v ' image/'

Anything printed is either an error status or not an image.

Find broken images across a whole site

Checking pages one by one doesn't scale past a handful. For a full site, you need a crawler that reads every page and tests every image URL it finds. Desktop SEO crawlers can do this, and linkbruno.com checks images along with links in its free 25-page scan, then lists each missing image with the page it's on.

Whatever you use, make sure it reports the source page for each broken image. A list of dead image URLs is not much help if you can't find which posts contain them.

How to fix them

Wrong case or path. Rename the file or fix the reference so they match exactly. Prefer root-relative paths (/images/logo.png) or absolute URLs in content, so moving a page doesn't break its images.

Deleted files. Restore from a backup or re-upload. If you can't, replace the image or remove the <img> tag. Don't leave an empty frame on the page.

Hotlinked images. Download the image (if you have the right to use it) and host it yourself. Relying on someone else's server for your page content is how this happened in the first place.

After a migration. Add redirects from the old image URLs to the new ones, the same way you would for pages, and then update the content so the redirect isn't needed.

Missing srcset sizes. Regenerate the image sizes. In WordPress, a thumbnail regeneration plugin does this; in a static site, rerun the image build step.

Make broken images less visible when they do happen

Images will break again eventually, so give them a graceful failure:

<img src="/images/chart.png" alt="Monthly signups, Jan to Jun" width="800" height="450">

Meaningful alt text shows in place of the image and keeps the content understandable.
width and height reserve the space, so a missing image doesn't make the layout jump.

You can also hide the broken-image icon with a small handler, but use it as a safety net, not a fix:

document.addEventListener('error', (e) => {
  if (e.target.tagName === 'IMG') e.target.classList.add('img-missing');
}, true);

A short checklist

Run the console snippet on your key pages after every deploy.
Keep image paths lowercase and root-relative.
Host your own images instead of hotlinking.
Ship redirects for old image URLs when you migrate.
Crawl the whole site for images, not just links, a few times a year.

Most broken images on a typical site trace back to one or two causes. Once you find the pattern, the fix is usually a single rename or redirect rule.

How to fix "Not found (404)" errors in Google Search Console

linkbruno.com — Wed, 28 Oct 2026 15:19:45 +0000

Open Google Search Console, go to Indexing > Pages, and there it is: Not found (404), sometimes with hundreds of URLs. It looks alarming. Most of the time it isn't, but a few of those URLs usually are worth fixing, and the trick is telling them apart quickly.

This guide walks through the report, how to decide what to do with each URL, and how to confirm the fix.

First: 404s are not a penalty

A 404 is the correct answer for a page that doesn't exist. Google has said for years that 404s on their own don't hurt the rest of your site's rankings. The report exists so you can spot URLs that should work but don't.

So the goal is not "zero 404s". The goal is:

no 404s on URLs that real people or real links still use
no internal links on your own site pointing to 404 pages
no 404 URLs in your sitemap

Step 1: Export the list

In Indexing > Pages, scroll to "Why pages aren't indexed" and click Not found (404). Use the export button at the top right to download the examples as a CSV or Google Sheet.

The list shows up to 1,000 example URLs and the date Google last crawled each one. Sort by "Last crawled" so recent problems come first.

Step 2: Sort the URLs into buckets

Skim the export and group the URLs. Nearly every 404 falls into one of these:

Bucket	Example	Usual action
Moved page	`/blog/old-slug` now lives at `/blog/new-slug`	301 redirect
Deleted on purpose	discontinued product, expired event	leave as 404 or 410
Typo in an internal link	`/pricng`	fix the link
Junk or spam URLs	`/?p=123abc`, random strings	ignore
Old URL structure	`/index.php?page=about` after a migration	redirect pattern
In your sitemap	sitemap still lists a removed page	remove from sitemap

Junk URLs, often created by spam sites linking to made-up paths, can be ignored. Google will crawl them less over time.

Step 3: Find who links to each URL

For the URLs that look important, find out where Google found them. Paste one into the URL Inspection bar at the top of Search Console. In the result, expand Page indexing and look at Discovery: it lists the sitemaps and a referring page, if Google has one.

If the referring page is on your site, that's an internal broken link. Fix the link itself, not just the destination.
If it's another site, the URL has a backlink. That's a strong reason to redirect it.
If it's your sitemap, regenerate or edit the sitemap.

Search Console only shows a sample. To find every internal page that links to a 404, run a crawl of your site with a broken link checker, which lists the source page for each broken link.

Step 4: Apply the right fix

Redirect moved pages with a 301

If there is a clear replacement, redirect the old URL to it. Send it to the closest match, not to the homepage. Google treats a redirect to an irrelevant page, especially the homepage, much like a soft 404.

nginx:

location = /blog/old-slug {
    return 301 /blog/new-slug;
}

# a whole old section
rewrite ^/news/(.*)$ /blog/$1 permanent;

Apache (.htaccess):

Redirect 301 /blog/old-slug /blog/new-slug
RedirectMatch 301 ^/news/(.*)$ /blog/$1

Netlify (_redirects file) or Cloudflare Pages:

/blog/old-slug   /blog/new-slug   301
/news/*          /blog/:splat     301

Next.js (next.config.js):

module.exports = {
  async redirects() {
    return [
      { source: '/blog/old-slug', destination: '/blog/new-slug', permanent: true },
    ];
  },
};

Let deleted pages stay deleted

If a page is gone and there's no good substitute, a 404 (or 410) is fine. Just make sure nothing on your own site still links to it and it's not in your sitemap.

Fix internal links at the source

A redirect hides an internal broken link but doesn't fix it. Update the link in your content, menu or template so it points at the live URL directly. That saves a redirect hop for every visitor and every crawl.

Step 5: Check your work before validating

Before telling Google you've fixed anything, test the URLs yourself:

while read -r url; do
  printf '%s  %s\n' "$(curl -s -o /dev/null -w '%{http_code} -> %{url_effective}' -L "$url")" "$url"
done < urls.txt

Each line shows the final status and where the URL ended up. You want 200 on the redirect target, or a deliberate 404/410 for removed pages.

Step 6: Click "Validate fix"

Back in the Not found (404) report, click Validate fix. Google re-crawls the affected URLs over the next days or weeks. The status moves to "Passed" for URLs that now resolve, and "Failed" for any that still return 404.

Don't worry if deliberate 404s keep the validation from passing. That's expected. The report is a to-do list, not a score.

Prevent the next batch

Most 404 reports come from the same few events: a redesign, a CMS migration, a changed slug, a removed product category. Before any of those:

Export a list of your current URLs from the sitemap.
Map each old URL to its new home.
Ship the redirects with the change, not afterwards.
Crawl the site right after launch.

If you'd rather not remember to re-crawl, linkbruno.com checks a site's links on a schedule and emails you when one breaks, with the page it's on. Either way, catching a broken link the week it appears beats finding it in Search Console months later.

How to check a website for broken links for free (5 methods that actually work)

linkbruno.com — Wed, 28 Oct 2026 15:19:26 +0000

Broken links rarely announce themselves. A page you linked to two years ago gets moved, a product URL changes during a redesign, or a partner's domain expires. Your page still loads, so nobody notices until a reader clicks and lands on an error.

The good news is that checking a site for broken links costs nothing. Here are five free methods, from the quickest to the most thorough, and what each one is good at.

What counts as a broken link?

Before you start, agree on what you are looking for. A link is worth fixing when it:

returns 404 Not Found or 410 Gone
returns a 5xx server error repeatedly, not just once
can't be reached at all (DNS failure, connection refused, timeout)
redirects in a loop, or through a long chain that ends on an error page
points to an image that no longer exists

Some responses look like errors but usually aren't. A 403 or 429 often means the other site blocks automated checks, and LinkedIn answers bots with a made-up 999 status. Treat those as "couldn't verify", not "broken".

Method 1: Google Search Console

If your site is verified in Search Console, open Indexing > Pages and look for the reason Not found (404). Click it to see example URLs Google tried to crawl.

Good for: internal URLs that Google knows about, including old URLs that other sites still link to.

Limits: it only shows what Googlebot crawled, it updates slowly, and it says nothing about your outbound links to other sites. Treat it as a second opinion, not your main check.

Method 2: Check one page in your browser

For a single page, the browser console is enough. Open the page, press F12, go to the Console tab and paste this:

const urls = [...new Set(
  [...document.querySelectorAll('a[href]')]
    .map(a => a.href.split('#')[0])
    .filter(u => u.startsWith(location.origin))
)];

for (const url of urls) {
  try {
    const res = await fetch(url, { method: 'HEAD', redirect: 'follow' });
    if (!res.ok) console.warn(res.status, url);
  } catch (e) {
    console.error('failed', url);
  }
}
console.log(`checked ${urls.length} internal links`);

It checks only same-origin links, because the browser blocks most cross-origin requests from reading the status. That makes it a fast way to test your own navigation, footer and in-content links after a change.

Good for: one page, right now, with no install.

Method 3: A free online broken link checker

Online checkers crawl your pages from their own servers and test every link, including links to other sites. The free tiers differ mainly in how many pages they crawl and whether you need an account.

For example, linkbruno.com runs a free scan of up to 25 pages with no signup and checks every link and image on them. It also reports redirect loops, long redirect chains, soft 404s ("200 OK" pages that actually say "not found") and links to domains that expired and turned into parked pages, which simple status checks miss.

Good for: a quick audit of a small site or the most important pages of a large one.

Method 4: A desktop crawler

Desktop SEO crawlers such as Screaming Frog have a free mode capped at 500 URLs. You enter your homepage, let it crawl, then filter the results by status code. Most of them can also show the inlinks for each broken URL, which tells you which page to edit.

Good for: one-off audits of medium-sized sites when you are comfortable with a spreadsheet-style interface.

Limits: it runs on your machine, so a big crawl ties up your laptop, and you have to remember to run it again.

Method 5: The W3C Link Checker

The W3C's free link checker (search for "W3C Link Checker") takes a URL and checks the links on that page, optionally following links a few levels deep. It is old-fashioned but honest, and it explains each problem in plain words.

Good for: a second opinion on a specific page, or checking static documentation.

How to read the results

Whatever tool you use, the raw list needs a quick triage:

Re-check failures once. Servers hiccup. A link that fails once and works a minute later is not broken.
Separate "blocked" from "broken". 401, 403, 429 and 999 responses usually come from bot protection. Open them in a browser before you touch anything.
Group by target URL. One dead URL in your footer shows up on every page. Fix the template once instead of editing 200 posts.
Find where the link lives. You need the page that contains the link, not just the dead URL. Most crawlers call this "source" or "inlinks".

How to fix what you find

Internal 404: update the link to the page's current URL. If the old URL was popular or has backlinks, also add a 301 redirect from it.
External 404: look for the page's new address on the same site. If it's gone, link to a different source or remove the link.
Redirect chains: point the link straight at the final destination.
Broken images: re-upload the file or fix the path. Remember that paths are case-sensitive on most servers.

Make it a habit, not a project

A single audit tells you what's broken today. Links keep breaking after that, a few at a time. A sensible routine for most sites:

Run a full check after every redesign, migration or URL change.
Re-check your highest-traffic pages monthly.
Look at Search Console's 404 report whenever you log in.

Even 15 minutes a month keeps the list short, and short lists actually get fixed.

How to find broken links with Playwright (a test you can drop into CI)

linkbruno.com — Tue, 27 Oct 2026 11:19:38 +0000

If you already use Playwright for end-to-end tests, you have everything you need to check a page for broken links. The browser can collect every link after JavaScript has run, and Playwright's built-in API client can request each one without opening a new tab. This post builds a small, practical broken link test step by step, and covers the parts that usually go wrong: false positives, rate limits and redirects.

The idea

Open a page with page.goto().
Collect every href from <a> elements (and src from images, if you want).
Request each unique URL with Playwright's request fixture.
Fail the test if any of them return an error.

Step 1: collect the links

a.href in the browser returns an absolute URL, so relative links are resolved for you.

// tests/broken-links.spec.ts
import { test, expect } from '@playwright/test';

const START_URL = process.env.START_URL ?? 'http://localhost:3000/';

async function collectLinks(page) {
  const hrefs = await page.$$eval('a[href]', (anchors) =>
    anchors.map((a) => (a as HTMLAnchorElement).href)
  );
  return [...new Set(hrefs)]
    .filter((u) => u.startsWith('http'))          // skip mailto:, tel:, javascript:
    .map((u) => u.split('#')[0]);                  // the fragment is not sent to the server
}

Filtering to http drops mailto:, tel: and javascript: links, which a request can't check. Stripping the #fragment avoids requesting the same page many times; checking that the anchor itself exists is a separate test (see the end).

Step 2: check each link

Playwright's request fixture is an APIRequestContext. It doesn't load the page in a browser, so it is fast, and it follows redirects by default.

async function checkLink(request, url: string) {
  const opts = { timeout: 15_000, maxRedirects: 10, failOnStatusCode: false };
  try {
    let res = await request.head(url, opts);
    // Many servers answer HEAD with 405 or 403 even when GET works.
    if ([403, 405, 501].includes(res.status())) {
      res = await request.get(url, opts);
    }
    return { url, status: res.status() };
  } catch (err) {
    return { url, status: 0, error: String(err).split('\n')[0] };
  }
}

Two details matter here:

HEAD first, GET as a fallback. HEAD is cheap because the server doesn't send the body. But plenty of servers and CDNs reject it, so retry with GET before you call a link broken.
failOnStatusCode: false. You want the status code back, not an exception.

Step 3: put it in a test

test('no broken links on the home page', async ({ page, request }) => {
  await page.goto(START_URL);
  const links = await collectLinks(page);

  const results = [];
  for (const url of links) {
    results.push(await checkLink(request, url));   // one at a time on purpose
  }

  const broken = results.filter((r) => r.status === 0 || r.status >= 400);
  for (const b of broken) console.log(`${b.status}  ${b.url}  ${b.error ?? ''}`);

  expect(broken, `${broken.length} broken links on ${START_URL}`).toEqual([]);
});

Run it:

START_URL=https://staging.example.com/ npx playwright test broken-links

The test checks links one at a time. That is slower than Promise.all, but firing fifty requests at once at a single external host is a good way to get rate-limited, which leads to the next section.

Step 4: deal with false positives

The first run on a real site usually "finds" links that work fine in a browser. Typical causes:

429 Too Many Requests. You checked too many links on one host too quickly. Group URLs by host and add a pause between requests to the same host.
403 Forbidden from sites behind bot protection. The page is fine for people; the site just refuses automated clients.
999 from LinkedIn. It is not a real HTTP status; it is LinkedIn refusing the request.
Timeouts from slow servers that are up but sluggish.

Don't fail the build on these. Report them separately:

const BLOCKED = new Set([401, 403, 429, 999]);

const broken  = results.filter((r) => r.status === 0 || (r.status >= 400 && !BLOCKED.has(r.status)));
const blocked = results.filter((r) => BLOCKED.has(r.status));

if (blocked.length) console.warn('Could not verify:', blocked.map((b) => b.url));

A failing check that is retried once a little later also removes most one-off network blips.

Step 5: more than one page

To cover a whole site, read your sitemap and loop over its URLs:

test('no broken links across the sitemap', async ({ page, request }) => {
  const xml = await (await request.get(new URL('/sitemap.xml', START_URL).href)).text();
  const pages = [...xml.matchAll(/<loc>(.*?)<\/loc>/g)].map((m) => m[1]).slice(0, 50);

  const seen = new Map();
  for (const p of pages) {
    await page.goto(p);
    for (const url of await collectLinks(page)) {
      if (!seen.has(url)) seen.set(url, await checkLink(request, url));
    }
  }
  const broken = [...seen.values()].filter((r) => r.status === 0 || r.status >= 400);
  expect(broken).toEqual([]);
});

Caching results in a Map means a link in your header or footer is checked once, not once per page. Cap the number of pages while you experiment, and raise the test timeout (test.setTimeout(...)) for larger sites.

Images and anchors

The same pattern works for images: collect img[src] with page.$$eval('img', imgs => imgs.map(i => i.currentSrc || i.src)). For in-page anchors, collect links with a #fragment, open the target page and check that document.getElementById(fragment) exists. A link to a removed section returns 200, so a status check alone will never catch it.

Running it in CI

Point START_URL at your preview deployment so a pull request that introduces a broken link fails before it merges. Keep external links in a separate, non-blocking job if your build shouldn't depend on other people's servers.

Where this stops

A Playwright test catches the links that are broken when it runs. Most links break later: a partner moves a page, a docs site restructures, a domain expires. That is the gap scheduled monitors fill. If you'd rather not maintain the crawler, linkbruno.com checks a site on a schedule and sends an email or Slack alert when a link stops working.

For a single page or a staging check in CI, the test above is about 60 lines and catches most problems before your readers do.

DEV Community: linkbruno.com

How to find mixed content (http:// links) on an HTTPS site

Two kinds of mixed content

Find it in the browser

Find it with grep in your source

Find it in a WordPress database

Crawl the rendered pages

What to do with each finding

Add a safety net

Keep it fixed

Related reading

Check links in Markdown docs with a 60-line Python script

What the script does

The code

Why HEAD first, then GET

Relative links matter too

Running it in CI

Handling flaky results

Where this stops

Related reading

How to find broken outbound links and replace them (using the Wayback Machine)

The three ways outbound links fail

Step 1: List every outbound link

Step 2: Check each link and record where it ends up

Step 3: Look at the suspicious ones

Step 4: Find a replacement

Step 5: Update links in bulk

Keep it from piling up again

Related reading

Anchor link not working? How to find and fix broken #section links

How anchor links work

Why anchor links break

Debug one broken anchor

Fix the sticky header problem

Find every broken anchor on a site

Make anchors stable

When the target is rendered by JavaScript

Summary

Related reading

How to find and fix broken images on a website

Why images break

Find broken images on one page

DevTools Network tab

A console snippet

Check every srcset candidate

Check images from the command line

Find broken images across a whole site

How to fix them

Make broken images less visible when they do happen

A short checklist

Related reading

How to fix "Not found (404)" errors in Google Search Console

First: 404s are not a penalty

Step 1: Export the list

Step 2: Sort the URLs into buckets

Step 3: Find who links to each URL

Step 4: Apply the right fix

Redirect moved pages with a 301

Let deleted pages stay deleted

Fix internal links at the source

Step 5: Check your work before validating

Step 6: Click "Validate fix"

Prevent the next batch

Related reading

How to check a website for broken links for free (5 methods that actually work)

What counts as a broken link?

Method 1: Google Search Console

Method 2: Check one page in your browser

Method 3: A free online broken link checker

Method 4: A desktop crawler

Method 5: The W3C Link Checker

How to read the results

How to fix what you find

Make it a habit, not a project

Related reading

How to find broken links with Playwright (a test you can drop into CI)

The idea

Step 1: collect the links

Step 2: check each link

Step 3: put it in a test