DEV Community: Sandeep Singh

Free Tools to Check Redirects, Broken Links, Mixed Content and Meta Tags (and When to Automate It)

Sandeep Singh — Tue, 20 Oct 2026 02:40:21 +0000

Disclosure: I build Uchik, a website monitoring tool. The free checkers in this article are ours. I've tried to make the manual methods useful whether or not you ever use them.

Most websites don't break in one dramatic moment. They break a little at a time. A product gets renamed and its old URL starts redirecting through three hops. A partner blog you linked to two years ago goes offline. Someone pastes an http:// image into a page template. A CMS plugin update quietly drops your meta descriptions.

None of these will page you at 3 a.m. They just sit there, costing you clicks, trust, and sometimes sales, until someone notices.

This guide covers four of the most common of these problems:

Redirect problems (chains, loops, wrong status codes)
Broken links (internal and external)
Mixed content on HTTPS pages
Missing or bad SEO meta tags

For each one, I'll explain what it is, how it hurts you, how to check it by hand with nothing but a browser and a terminal, and which free tool will do the same check faster. At the end, I'll talk about when doing this by hand stops making sense.

All four free tools live at uchik.com/tools. None of them need an account.

1. Redirect problems

What it is

A redirect tells the browser (and search engines) "this page has moved, go here instead." That's healthy. The problems start when redirects pile up:

Redirect chains: URL A → B → C → D. Each hop is another round trip before the visitor sees anything.
Redirect loops: A → B → A. The browser gives up with "too many redirects" and the page never loads.
Wrong redirect type: a temporary 302 used for a permanent move, when a 301 (or 308) is what you mean.
Mixed hops: http://example.com → https://example.com → https://www.example.com → https://www.example.com/. Four URLs for one homepage.

Chains usually build up over time: a site moves to HTTPS, then to www, then changes its URL structure, and each change adds a rule on top of the old ones instead of updating them.

How it hurts rankings and sales

Speed. Each hop adds latency before the first byte of the real page arrives, which hurts most on mobile networks.
Crawling. Google says Googlebot follows a limited number of redirect hops in a chain. Long chains waste crawl effort and can stop a crawler before it reaches the final page.
Signals. Internal links that point at redirecting URLs make search engines do extra work to figure out which URL is canonical. Linking straight to the final URL is cleaner.
Lost visitors. A loop is a fully broken page. If it's a checkout or a product page, that's lost revenue, plain and simple.

I wrote a store-specific version of this in Redirect Chains in Shopify After Changing Product Handles if you run on Shopify.

How to check it manually

curl will show you every hop:

curl -sIL http://example.com | grep -iE "^(HTTP|location)"

-I asks for headers only, -L follows redirects, and the grep keeps just the status lines and Location headers. You'll see something like:

HTTP/1.1 301 Moved Permanently
Location: https://example.com/
HTTP/2 301
location: https://www.example.com/
HTTP/2 200

That's a two-hop chain. Ideally, http://example.com would go straight to https://www.example.com/ in one hop.

In a browser, open DevTools → Network, tick Preserve log, and load the URL. Each redirect shows up as its own row with a 3xx status.

Things to look for:

More than one hop for any URL you control.
302 or 307 where the move is actually permanent.
Any URL that appears twice in the list (a loop).
Internal links, sitemaps, or canonical tags that point at a URL which redirects.

The free tool

The Uchik Redirect Checker does the curl trace for you. Paste a URL and it lists every hop with its status code (301, 302, 307, 308), flags loops and HTTP → HTTPS hops, and shows the response headers and timing for each step.

2. Broken links

What it is

A broken link points to a page that no longer works: usually a 404 Not Found or 410 Gone, sometimes a 5xx server error, a DNS failure, or a timeout.

There are two kinds, and they behave differently:

Broken internal links: links between your own pages. You caused these, usually by deleting, renaming, or moving a page without updating links to it.
Broken external links: links from your site to someone else's. You didn't cause these, but they still show up on your page. Sites shut down, restructure, or move behind paywalls.

How it hurts rankings and sales

Visitors hit a dead end. Someone who clicks "See sizing guide" and gets a 404 is less likely to keep shopping. On a store, a broken link to a product or the checkout is a direct path to a lost sale.
Crawlers hit a dead end. Internal links are how search engines find and understand your pages. A broken internal link is a dead branch: link value and discovery stop there.
Trust. An article full of dead references looks abandoned, even if the content is still good.

I want to be careful here: a few broken outbound links won't tank your rankings on their own, and Google has said 404s are a normal part of the web. The real cost is to the people using your site, plus the wasted internal linking. I went into the ranking question in more detail in Broken Links and Core Web Vitals: What Actually Affects Rankings.

How to check it manually

For a single page, pull every link and check its status:

URL="https://example.com/some-page"
curl -s "$URL" \
  | grep -oE 'href="https?://[^"]+"' \
  | sed -E 's/href="([^"]+)"/\1/' \
  | sort -u \
  | while read -r link; do
      code=$(curl -s -o /dev/null -w "%{http_code}" -L --max-time 10 "$link")
      echo "$code $link"
    done | grep -vE "^(200|204)"

This only catches absolute links (relative links like /about need to be resolved against the page URL first), and some sites return 403 to curl even when the page works fine in a browser. Treat 403 and 429 results as "check by hand," not "broken."

For a whole site, a crawler is the realistic option. wget can do a rough pass:

wget --spider -r -l 3 -nd -nv -o crawl.log https://example.com
grep -B1 "broken link" crawl.log

Other places to look:

Google Search Console → Pages: lists URLs Google found that return 404, and often where it found them.
Your server or CDN logs: filter for 404 responses and look at the referrer to see which page holds the bad link.

The free tool

The Uchik Broken Link Checker takes a page URL, finds the links on it, and checks each one, so you can see which are dead without writing a script. It's a quick way to clean up a single important page: your homepage, a top blog post, or a product page that gets a lot of traffic.

3. Mixed content

What it is

Mixed content happens when a page loaded over https:// pulls in some resources over plain http://. For example:

<img src="http://example.com/images/hero.jpg">
<script src="http://cdn.example.com/widget.js"></script>

Browsers treat the two kinds differently:

Active mixed content (scripts, stylesheets, iframes, fetch/XHR requests) is blocked outright by modern browsers, because an attacker on the network could change it.
Passive mixed content (images, audio, video) is often upgraded to HTTPS automatically by modern browsers. If the HTTPS version doesn't exist, the resource fails to load.

It nearly always comes from one of three places: old content written before the site moved to HTTPS, hard-coded URLs in a theme or template, or third-party embeds.

How it hurts rankings and sales

Broken pages. A blocked script can mean a broken menu, a missing "Add to cart" button, or a payment widget that never loads. A blocked stylesheet can leave a page unstyled.
Missing images. An auto-upgraded image that doesn't exist on HTTPS just disappears, leaving gaps on product and blog pages.
Trust warnings. Browsers may drop the "secure" indicator in the address bar or show a warning, which is the last thing you want on a checkout page.
HTTPS as a signal. Google has used HTTPS as a lightweight ranking signal for years. A page that's only partly secure isn't getting the full benefit of the move.

If you're on WordPress, HTTPS and Mixed Content on WordPress After Installing SSL walks through the database and plugin fixes.

How to check it manually

Open the page, open DevTools, and check the Console. Browsers log a "Mixed Content" warning or error for each insecure resource, with its URL. The Security panel in Chromium browsers will also tell you whether the page is fully secure.

From the command line, you can grep the HTML for insecure resource URLs:

curl -s https://example.com/ \
  | grep -oiE '(src|href|action)="http://[^"]+"' \
  | sort -u

This will also list ordinary <a href="http://..."> links to other sites. Those are not mixed content, since clicking a link just goes to a new page. Focus on src attributes, stylesheets (<link rel="stylesheet" href=...>), and form action URLs. Also note that this only sees the raw HTML. Resources added later by JavaScript, or referenced inside CSS files (url(http://...)), only show up in the browser console.

The long-term fix is to use https:// URLs (or root-relative ones like /images/hero.jpg) in your content and templates. As a safety net, the Content-Security-Policy: upgrade-insecure-requests header tells browsers to upgrade insecure requests on your pages automatically.

The free tool

The Uchik Mixed Content Checker loads an HTTPS page and lists the resources it requests over plain HTTP, so you can find the template or post that needs fixing without combing through the console.

4. Missing or bad SEO meta tags

What it is

Meta tags are the bits of the <head> that tell search engines and social platforms what a page is. The ones worth checking on every page:

Tag	What it does
`<title>`	The clickable headline in search results and the browser tab
`<meta name="description">`	Often used as the snippet under the title in search results
`<link rel="canonical">`	Tells search engines which URL is the "real" version of the page
`<meta name="robots">`	Can tell search engines not to index the page (`noindex`)
`<meta name="viewport">`	Needed for a page to display properly on mobile
Open Graph (`og:title`, `og:description`, `og:image`)	Controls the preview card when the link is shared on social and chat apps

Common problems: the tag is missing, every page has the same title, the title is the template default ("Home" or "Product"), the canonical points to the wrong page, or a noindex left over from a staging site made it to production.

How it hurts rankings and sales

A stray noindex can take a page, or a whole site, out of search results. This is the one that really matters, and it's surprisingly common after a launch or a redesign.
A wrong canonical can make search engines index a different URL than the one you want, or ignore the page as a duplicate.
Weak or duplicate titles and descriptions make your result less attractive and less clearly relevant. Search engines may rewrite them, but you lose control over what people see.
Missing Open Graph tags mean shared links show up with no image or the wrong text, which makes them less likely to be clicked.

For a full checklist with recommended formats, see The SEO Meta Tags Checklist: Title, Description, Canonical and Open Graph.

How to check it manually

In a browser, use View Page Source (not DevTools' Elements panel, which shows the page after JavaScript runs) and search for <title, description, canonical, and robots.

From the terminal:

curl -s https://example.com/ \
  | grep -oiE '<title>[^<]*</title>|<meta[^>]+(name|property)="(description|robots|viewport|og:[a-z]+)"[^>]*>|<link[^>]+rel="canonical"[^>]*>'

Also check the X-Robots-Tag HTTP header, which can apply noindex without anything showing up in the HTML:

curl -sI https://example.com/ | grep -i x-robots-tag

In Google Search Console, the URL Inspection tool shows whether a page can be indexed and which canonical Google picked, which may not be the one you declared.

The free tool

The Uchik Meta Tag Checker fetches a page and shows its title, description, canonical, robots directives, and social tags in one view, and flags the ones that are missing. It's the quickest way to confirm a fresh deploy didn't ship with a staging noindex.

A quick manual routine

If you're doing this by hand, here's a simple routine that covers the basics for a small site:

Homepage and top 5 pages: run each through the meta tag checker. Confirm there's no noindex and that the canonical points to itself.
Your main domain variants: run http://, https://, www and non-www through the redirect checker. Each should reach the final URL in one hop.
Your money pages (pricing, product, checkout, signup, contact): run each through the broken link checker and the mixed content checker.
After any migration, theme change, or plugin update: repeat all of the above.

That takes maybe 20–30 minutes for a handful of pages, and it'll catch the worst problems.

When to automate it

The manual routine works, but it has two weaknesses.

First, it's a snapshot. Your site keeps changing after you check it. External links rot on their own schedule. A teammate edits a page. An app update changes a template. The check you did last Tuesday doesn't tell you about the product page that went down on Thursday.

Second, it doesn't scale. Checking five pages by hand is fine. Checking every page on a 300-product store, or across ten client sites, every week, is the kind of job that quietly stops getting done.

A rough rule of thumb I'd suggest:

Check by hand if you have a small, mostly static site that you rarely change. Run the routine after every significant change and a few times a year.
Automate if you run a store, publish often, have more than a few dozen pages, manage sites for clients, or if a broken page directly costs you money. I wrote more about how often to check what in Automating Website Monitoring: What to Check Daily vs Weekly vs Monthly.

This is the problem we built Uchik to solve. It runs seven checks on your site automatically every day:

Broken internal links
Broken external links
Missing images
Dead checkout and product pages
Mixed-content warnings
Redirect problems
Missing SEO tags

Instead of remembering to run a routine, you get a report that tells you what broke and where. You can see what that looks like in the sample report, or read how it works.

Whether you automate with Uchik, another tool, or your own scripts built from the commands above, the point is the same: these problems are cheap to fix when you catch them early and expensive when your customers find them first.

Summary

Problem	Quick manual check	Free tool
Redirect chains and loops	`curl -sIL URL`	Redirect Checker
Broken links	`wget --spider` or a link-check loop	Broken Link Checker
Mixed content	DevTools Console	Mixed Content Checker
Meta tags	View Source + `curl -sI` for `X-Robots-Tag`	Meta Tag Checker

All the free tools are at uchik.com/tools. If you'd rather have all of this checked every day without thinking about it, you can sign up for free.

Got a manual check I missed? Tell me in the comments.

A Technical SEO Checklist for Launching a New Website

Sandeep Singh — Sun, 18 Oct 2026 19:46:28 +0000

Launch day is when small configuration mistakes do the most damage. A noindex left over from staging, a robots.txt copied from the dev server, a 404 page that returns 200, or a domain switch with no redirects can each keep a good site out of search for weeks, and none of them is visible to someone just looking at the homepage.

This is the checklist I run for a new site launch, split into before launch, launch day, and the first month after. Each item links to the documentation behind it, mostly Google Search Central, so you can check the reasoning rather than take my word for it.

Before launch

1. Decide your canonical hostname

Pick one version: https://www.example.com or https://example.com. Every other variant (http://, the other www choice, trailing-slash differences) should 301 to it in one hop.

Google calls redirects and rel="canonical" strong canonicalization signals and sitemap inclusion a weak one (Google: Consolidate duplicate URLs). Use redirects for hostname variants and a self-referencing canonical on each page.

Test all four combinations:

for u in http://example.com http://www.example.com https://example.com https://www.example.com; do
  echo "== $u"
  curl -sIL "$u" | grep -iE '^(HTTP/|location:)'
done

Each should end at the same final URL with no more than one redirect.

2. HTTPS everywhere

Install the certificate, redirect HTTP to HTTPS, and check for mixed content: anything on the page loaded over http://. MDN's mixed content guide explains what browsers upgrade and what they block. Google lists being "served in a secure fashion" among page experience considerations (Google: Page experience). Certificates also expire; Let's Encrypt certificates last 90 days, so make sure auto-renewal works before you rely on it. If you're on WordPress, my post on HTTPS and Mixed Content on WordPress After Installing SSL has the platform-specific steps.

3. Real 404s

Request a URL that doesn't exist:

curl -s -o /dev/null -w '%{http_code}\n' https://example.com/this-page-does-not-exist-123

It must return 404 (or 410), not 200. Google says that if a page's content suggests an error, "an empty page or an error message," Search Console will report a soft 404 (Google: HTTP status codes). Single-page apps and some themes get this wrong by default. Also don't redirect every missing URL to the homepage. Google treats those as soft 404s too (Google Search Console Help).

4. Titles and meta descriptions

Every indexable page needs a unique, descriptive <title>. Google's title link guidance asks for unique, concise titles and notes Google may rewrite them. Write a meta description for key pages. Google may use it for the snippet but isn't required to. Add Open Graph tags so shares look right. I covered all of these in detail in The SEO Meta Tags Checklist: Title, Description, Canonical and Open Graph.

5. Crawlable links and navigation

Google follows links in <a href> elements. Navigation built from click handlers on <div>s or <span>s may not be crawled (Google: Link best practices). Check that every important page is reachable through normal links from the homepage, and that anchor text describes the destination.

6. Core Web Vitals baseline

Run PageSpeed Insights or Lighthouse on your main templates (home, article/product, category). The "good" thresholds are LCP 2.5 seconds or less, INP 200 ms or less and CLS 0.1 or less, measured at the 75th percentile of page loads (web.dev: Web Vitals). Before launch you only have lab data. Search Console's Core Web Vitals report uses real-user field data and fills in once you have traffic. Common launch-time fixes are image dimensions, not lazy-loading the hero image, and trimming third-party scripts.

7. If you're replacing an old site: map redirects

This is the most expensive item to skip. Export every URL from the old site (sitemap, crawl, analytics, and Search Console's top pages), map each one to its closest new equivalent, and 301 it. Google's site move guide recommends keeping redirects for at least a year, and its Change of Address tool is only for moves to a new domain. My full recovery process is in 404 Errors After a Site Migration or Redesign: A Recovery Checklist.

Launch day

8. Remove the staging `noindex`

The classic launch bug. Staging sites are usually kept out of search with <meta name="robots" content="noindex">, an X-Robots-Tag: noindex header, or WordPress's "Discourage search engines" setting, and the flag survives the launch.

Check both places:

curl -sI https://example.com/ | grep -i x-robots-tag
curl -s https://example.com/ | grep -io '<meta[^>]*robots[^>]*>'

Then check a few inner templates too. A noindex can live in one template only.

9. Fix `robots.txt`

A staging Disallow: / copied to production blocks crawling of everything. Two things from Google's robots.txt introduction are worth knowing:

robots.txt manages crawling and "is not a mechanism for keeping a web page out of Google."
For noindex to work, the page "must not be blocked by a robots.txt file," because a blocked crawler "will never see the noindex rule" (Google: Block indexing).

So don't combine them on the same URL. For pages that shouldn't be indexed, allow crawling and use noindex. Use Disallow for things like infinite filter URLs or internal search results that waste crawl activity.

Add a Sitemap: line pointing to your sitemap.

10. Sitemap

Generate an XML sitemap containing only canonical, indexable URLs that return 200. No redirects, no noindexed pages, no staging hostnames. Many platforms do this automatically (WordPress has served /wp-sitemap.xml since 5.5). Google says small, well-linked sites of about 500 pages or fewer may not need one (Google: Sitemaps overview), but a sitemap is cheap and it gives Search Console a list to report against.

Quick check that every sitemap URL returns 200:

curl -s https://example.com/sitemap.xml | grep -oE '<loc>[^<]+' | sed 's/<loc>//' \
 | while read -r u; do echo "$(curl -s -o /dev/null -w '%{http_code}' "$u") $u"; done | grep -v '^200'

No output means every URL listed returns 200 directly. (For a sitemap index, run it on each child sitemap.)

11. Search Console

Verify the site, preferably as a Domain property so it covers every protocol and subdomain. Submit the sitemap. Use the URL Inspection tool on the homepage and a few key pages. Its live test shows what Google can fetch and render, and you can request indexing. Add teammates with the right permission level rather than sharing a login. Bing Webmaster Tools is worth setting up at the same time.

12. Analytics

Confirm your analytics tag fires on every template, including thank-you and checkout pages, and that staging traffic is excluded. It's not an SEO ranking factor, but you'll want data from day one to judge everything else.

The first month

13. Watch Page indexing

In Search Console's Page indexing report, look for:

Excluded by 'noindex' tag on pages you want indexed (a leftover from step 8)
Blocked by robots.txt on pages you want indexed (step 9)
Not found (404), usually old URLs missing a redirect (step 7) or broken internal links
Soft 404 (step 3)
Duplicate, Google chose different canonical than user, which suggests mixed signals between redirects, canonicals and internal links (step 1)

New sites take time to be crawled and indexed, so don't panic over a slow first week. Look for patterns, not individual URLs.

14. Crawl your own site

Run a full crawl after launch. Screaming Frog SEO Spider is free up to 500 URLs (limits). Look for:

Internal links to 404s or to redirected URLs (update them to the final URL)
Redirect chains, especially left over from the old site
Missing or duplicate titles and descriptions
Broken images
Pages with no internal links pointing to them

15. Re-test after every deploy

Launch isn't the only risky moment. Every deploy can bring back a noindex, break a template's canonical, or remove a page. Put the checks from steps 1, 3, 8 and 10 into your deploy pipeline or a scheduled job.

Ongoing monitoring

Steps 13 to 15 are where launches usually slip: they need repeating, and nobody owns them once launch week is over.

Disclosure: I build Uchik, which automates the recurring part. Uchik crawls a site daily and emails a report of broken links, missing images, redirect chains and loops, mixed content and pages that can't be reached. The how it works page explains the crawl, the features page lists the checks, and the sample report shows the output. Honest limits: it isn't a replacement for Search Console's indexing data; it reads server-delivered HTML, so links added only by JavaScript may be missed; its redirect-chain warning targets chains longer than 3 hops, so use the curl loop above to enforce one-hop redirects; and the free plan covers one site. You can sign up for free.

The checklist

Before launch

[ ] One canonical hostname; all variants 301 to it in one hop
[ ] Self-referencing canonicals on every indexable page
[ ] HTTPS everywhere, no mixed content, auto-renewal confirmed
[ ] Missing URLs return 404/410, not 200 or a homepage redirect
[ ] Unique titles; descriptions on key pages; Open Graph tags
[ ] Navigation uses real <a href> links
[ ] Core Web Vitals lab baseline on main templates
[ ] Old-site URL inventory mapped to 301s (if replacing a site)

Launch day

[ ] No noindex meta tag or X-Robots-Tag on live templates
[ ] robots.txt has no staging Disallow: /; includes Sitemap:
[ ] Sitemap lists only 200, canonical, indexable URLs
[ ] Search Console verified, sitemap submitted, key URLs inspected
[ ] Analytics firing; staging excluded

First month and beyond

[ ] Page indexing report reviewed weekly
[ ] Full crawl: broken links, redirects, titles, images, orphan pages
[ ] Launch checks automated for every deploy

Image SEO for Blogs: Finding Missing, Broken and Unindexable Images

Sandeep Singh — Sun, 18 Oct 2026 19:46:12 +0000

Most blog posts lean on images: screenshots, diagrams, charts, product photos, hero images for social shares. And most blogs carry some broken ones that nobody has noticed. The author's browser cached the image years ago, the post looks fine to them, and a reader sees an empty box with a tiny broken-image icon.

Broken images are a quality problem first: a tutorial with missing screenshots stops being a tutorial. They are also an image SEO problem, because an image that returns a 404, or that crawlers can't find in the first place, can't show up in Google Images, Discover or the thumbnails beside text results.

This guide covers why blog images break, how to find every broken or missing image on a site, and the image SEO basics that Google documents, with sources for each.

Why blog images break

In rough order of how often I see them:

Deleted media. Someone cleans up the media library and removes files still used in old posts. In WordPress, deleting a file from the library doesn't edit the posts that embed it.
Domain or HTTPS moves. Images hard-coded as http://old-domain.com/wp-content/uploads/... break, or get blocked as mixed content, after a move.
Hotlinked images. Images embedded straight from another site disappear when that site reorganises, deletes them, or blocks hotlinking.
CDN or storage changes. Moving uploads to S3, a CDN or a new image service changes URLs. Old posts keep the old URLs.
Expired third-party embeds. Screenshot services, badge generators and chart widgets shut down or change URL schemes.
Case and filename mismatches. Screenshot.PNG works on one server and 404s on a case-sensitive one after a migration.
Broken srcset entries. The src works, but one of the resized versions listed in srcset is missing, so only some devices see a broken image. These are the hardest to notice by eye.

Step 1: Find every broken image on the blog

Crawl the site and check image URLs

Checking pages one by one doesn't scale. A crawler collects every <img> URL across the site and requests each one.

Screaming Frog SEO Spider (free up to 500 URLs, limits) lists images under the Images tab and response codes for every resource. Filter for Client Error (4xx) and use Inlinks to see which posts embed each broken image.
Google Search Console won't list broken images directly, but its Page indexing and Core Web Vitals reports help with the related problems below.

A quick script for a single post

For spot checks, this pulls the src and every srcset candidate from a page and checks each one:

import re, sys, urllib.request, urllib.parse

page = sys.argv[1]
req = urllib.request.Request(page, headers={"User-Agent": "img-check/1.0"})
html = urllib.request.urlopen(req, timeout=20).read().decode("utf-8", "replace")

urls = set()
for tag in re.findall(r"<(?:img|source)\b[^>]*>", html, re.I):
    m = re.search(r'\ssrc="([^"]+)"', tag)
    if m:
        urls.add(m.group(1))
    s = re.search(r'\ssrcset="([^"]+)"', tag)
    if s:
        for part in s.group(1).split(","):
            if part.strip():
                urls.add(part.strip().split()[0])

for u in sorted(urls):
    if u.startswith("data:"):
        continue
    full = urllib.parse.urljoin(page, u)
    try:
        r = urllib.request.urlopen(urllib.request.Request(full, method="HEAD",
            headers={"User-Agent": "img-check/1.0"}), timeout=15)
        code = r.status
    except urllib.error.HTTPError as e:
        code = e.code
    except Exception as e:
        code = type(e).__name__
    print(code, full)

Run it with python3 imgcheck.py https://yourblog.example/some-post/. Some servers reject HEAD requests; if you get a 405, retry that URL with GET.

Check for mixed content images

On an HTTPS page, an image loaded over http:// is mixed content. MDN explains that browsers now try to upgrade "upgradable" content such as images to HTTPS, but if the image isn't available over HTTPS the upgrade fails and the image doesn't load. MDN also notes that images in srcset or <picture> aren't upgraded and are blocked instead (MDN: Mixed content). Search your post content for src="http:// and srcset="http://. I covered the WordPress side of this in HTTPS and Mixed Content on WordPress After Installing SSL.

Step 2: Fix them

Cause	Fix
File deleted, original available	Re-upload to the same path, or update the post to the new path
File gone, no copy	Check the Wayback Machine for an archived copy; otherwise replace or remove the image and adjust the text
Old domain or `http://` URLs	Search-replace in the database (on WordPress, WP-CLI `search-replace` handles serialized data safely)
Hotlinked image gone	Host your own copy if licensing allows, or replace it
Missing `srcset` sizes	Regenerate thumbnails or resized versions
Case mismatch	Rename the file or fix the reference so they match exactly

Then re-crawl. Fixing images by hand is error-prone, and the re-crawl is what proves the fix.

Step 3: Make images indexable

A working image can still be invisible to search. Google's image SEO best practices set out the basics.

Use real `<img>` elements

Google says it "can find images in src attribute of <img> element (even when it's a child of other elements, such as the <picture> element)" and that it "doesn't index CSS images." A hero image set as a CSS background-image won't be indexed. If the image matters for search, use an <img>.

Always include a `src` fallback

Google notes that "some browsers and crawlers don't understand" srcset and <picture>, and recommends you "always specify a fallback URL using the src attribute." A <picture> element should contain an <img> with a src.

Use supported formats

Google Search supports BMP, GIF, JPEG, PNG, WebP, SVG and AVIF in <img src>, and suggests filename extensions match the file type (same source).

Consider an image sitemap

Image sitemaps tell Google about images it might not otherwise find, "such as images your site reaches with JavaScript code." Each <url> can list up to 1,000 <image:image> entries, and image URLs can be on other domains, such as a CDN.

Step 4: Alt text, filenames and context

Google is explicit: "The most important attribute when it comes to providing more metadata for an image is the alt text," which "also improves accessibility for people who can't see images." It warns against keyword stuffing in alt attributes, which "may cause your site to be seen as spam" (Google).

Practical rules for blog images:

Describe what's in the image in a short sentence. For a screenshot: what it shows and why it's there ("WordPress Site Health screen with the HTTPS status warning").
Decorative images can use an empty alt="" so screen readers skip them.
Image links: Google notes alt text acts as anchor text when an image is a link, so describe the destination.
Filenames: Google says filenames give "very light clues." wordpress-site-health-https.png beats IMG00023.PNG.
Placement: put images near the text they illustrate. Google uses page content and captions to understand them.
Same image, same URL: if an image appears on many pages, reference it with one consistent URL so it can be cached and reused.

A crawl export of <img> tags with missing alt attributes, filtered to content images, gives you a manageable to-do list.

Step 5: Images and Core Web Vitals

Images affect two of the three Core Web Vitals.

CLS: always set dimensions

web.dev lists "images without dimensions" first among the most common causes of poor Cumulative Layout Shift (web.dev: Optimize CLS). Set width and height attributes, or use CSS aspect-ratio, so the browser reserves space before the image loads.

LCP: don't lazy-load the hero

web.dev's lazy-loading guide warns: "Don't lazy-load images that are likely to be in-viewport when the page loads, especially LCP images" (web.dev). WordPress has added loading="lazy" automatically since 5.5, and only to images with both width and height attributes (Make WordPress Core), so check that your theme isn't lazy-loading the featured image at the top of each post.

To be fair about scale: a broken image below the fold is a user-experience bug, not a ranking crisis. I go into what affects rankings and what doesn't in Broken Links and Core Web Vitals: What Actually Affects Rankings.

Step 6: Social preview images

The og:image meta tag sets the image used when a post is shared, and Google lists it among the ways to suggest a preferred image for a page. Google advises choosing an image that is "relevant and representative of the page" and avoiding generic images such as a site logo. When og:image points at a deleted file, every share of that post shows a blank card. Include og:image URLs in your broken-image checks.

Keep it from coming back

Before deleting media, check whether it's still used. On WordPress, media plugins or a database search for the filename will tell you.
After any migration, CDN change or HTTPS switch, re-crawl images specifically.
Avoid hotlinking images you don't control.
Monitor continuously. Images break between audits, and the person who notices is usually a reader.

Disclosure: I build Uchik. Uchik crawls a site daily and includes broken images alongside broken links and redirect problems in its emailed report, with the page where each was found. How it works and the features page explain the checks. Limits, also covered in the FAQ: it reads server-delivered HTML, so images injected only by JavaScript may be missed; it doesn't judge alt text quality; and the free plan covers one site. You can sign up for free. Screaming Frog's free version and Search Console are both good options too.

Checklist

[ ] Full crawl with image response codes; 4xx images fixed or removed
[ ] srcset and <picture> sources checked, not just src
[ ] No http:// image URLs on HTTPS pages
[ ] Important images use <img> (not CSS backgrounds), with a src fallback
[ ] Supported formats; extensions match file types
[ ] Image sitemap considered for JavaScript-loaded images
[ ] Descriptive alt text on content images; empty alt on decorative ones
[ ] Descriptive filenames
[ ] width/height or aspect-ratio on every image
[ ] Hero/LCP image not lazy-loaded
[ ] og:image URLs return 200
[ ] Re-crawl after migrations, CDN moves and media clean-ups

Newsletter Link Rot on Substack, Ghost and beehiiv: Archive Checks That Work

Sandeep Singh — Sun, 18 Oct 2026 19:32:55 +0000

Every newsletter issue is sent once and read for years. The email lands in inboxes on Tuesday. The web version sits in your archive, gets indexed, gets shared, and becomes the thing new readers browse before subscribing.

The links in those archive pages quietly decay. Sources move, tools shut down, sponsors rebrand, tweets disappear, and your own old URLs change when you switch platforms or add a custom domain. Pew Research Center found that 38% of webpages that existed in 2013 were no longer accessible a decade later, and that even of pages collected in 2021, about one in five were gone two years on (Pew Research Center, 2024). A newsletter that links to a dozen sources an issue builds up dead links fast.

This guide is practical and platform-specific: what to check before you send, how to audit an archive on Substack, Ghost or beehiiv, the custom domain and migration traps, and a routine that fits around a weekly publishing schedule.

Part 1: The pre-send check (two minutes per issue)

The cheapest dead link to fix is one that never ships. Before every send:

Open the web preview and click every link. Yes, every one, especially the sponsor link and your main source.
Watch for redirects to homepages. If a source link lands on the site's homepage instead of the article, the article has probably moved or been removed. Find the current URL.
Strip tracking junk from links you copied (?utm_..., ?ref=..., session IDs). They make URLs longer and more fragile.
Prefer stable sources: original research, official docs and the publisher's own page over syndicated copies, screenshots of screenshots, or social posts.
Save key sources to the Wayback Machine. Submitting a URL to web.archive.org/save before you publish means a snapshot exists if the page later disappears.

For longer issues, a quick command-line pass over the links on the web preview catches typos you'd miss by eye:

curl -sL "https://yournewsletter.example/p/issue-slug" \
 | grep -oE 'href="https?://[^"]+"' | cut -d'"' -f2 | sort -u \
 | while read -r u; do
     printf '%s %s\n' "$(curl -s -o /dev/null -L --max-time 15 -w '%{http_code}' "$u")" "$u"
   done | sort

Anything that isn't 200 deserves a look. Some sites return 403 to scripts but work in a browser, so treat those as "check by hand", not "broken".

Part 2: Find every archive URL with the sitemap

You can't audit an archive you can't list. Fortunately, the major platforms publish sitemaps:

Substack publications serve a sitemap at /sitemap.xml listing the archive, about page and individual posts under /p/…. You can see this on Substack's own publication at on.substack.com/sitemap.xml.
Ghost "automatically creates and updates an XML sitemap for your website" (Ghost: SEO in Ghost), at /sitemap.xml, which links to separate sitemaps for posts, pages, tags and authors.
beehiiv and other platforms generally provide a sitemap too. Check yourdomain/sitemap.xml, or look for a sitemap reference in /robots.txt.

Extract the post URLs:

curl -sL https://yournewsletter.example/sitemap.xml | grep -oE '<loc>[^<]+' | sed 's/<loc>//' > archive.txt
# For a Ghost sitemap index, repeat for each child sitemap listed (e.g. sitemap-posts.xml)

Now you have the complete list of issue pages to check.

Part 3: Audit the archive

Check every outbound link

Feed archive.txt into a crawler in list mode. Screaming Frog SEO Spider does this with Mode → List and is free up to 500 URLs (limits), which covers years of weekly issues. Configure it to check external links, then filter outbound links by 4xx/5xx and use the Inlinks pane to see which issue each dead link is in.

Prioritise

Fix in this order:

Issues that still get traffic. Check your platform's post stats or analytics.
Issues linked from your welcome email, about page or "start here" page. New subscribers read these first.
Sponsor links. A sponsor paid for a working link.
The main source of each issue, before passing mentions.

Fix

Moved: update to the new URL.
Gone but archived: link to the Wayback Machine snapshot and say it's an archived copy. The Wayback availability API can find the closest snapshot for a URL and date, which helps for bulk fixes.
Gone, no archive: replace with an equivalent source or remove the link and adjust the sentence.

Edit the web version of each issue; the emails already delivered can't be changed. Keep a short changelog of what you fixed and when, so a later audit doesn't re-check the same dead sources and you can spot which sites rot most often.

Part 4: Your own URLs, the links you can actually control

The most damaging rot in a newsletter archive is often self-inflicted: your own URLs changing.

Adding a custom domain

Moving from yourname.substack.com to your own domain is a common step. Substack says that when you add a custom domain, "all previous links using the Substack subdomain will automatically redirect to your new custom domain" (Substack: Bulletin). Its help centre recommends hosting on a subdomain such as www. with the root domain redirected to it (Substack Help: custom domains). After the switch, test a handful of old subdomain links yourself, including from old emails, and confirm they land on the right post in one redirect.

Changing platforms

Platform moves usually change URL patterns. Ghost's redirect tutorial includes specific rules for handling the /p/ post paths used by Substack and beehiiv when migrating to Ghost, and explains that redirects are managed by uploading a redirects file in Ghost's settings (Ghost: Implementing redirects). Whatever the direction of your move:

Before migrating, save the full old sitemap (archive.txt above). It's your old-URL inventory.
Map old patterns to new ones (often a single rule per pattern).
After migrating, run the old list through a status check. Every old URL should 301 to its new home in one hop.
Update internal links in recent issues and your about/welcome pages so they don't depend on redirects.

I wrote a fuller recovery process for site moves in 404 Errors After a Site Migration or Redesign: A Recovery Checklist. It applies just as much to newsletter archives.

Links between your own issues

"As I wrote last month…" links point at your own archive. Use the canonical URL of the post (custom domain, not the old subdomain) so they never rely on a redirect.

Links in email bodies

Most email platforms rewrite links for click tracking through their own domain. That works while the account is active. If you change platforms or tracking domains, links in emails already sitting in inboxes can stop resolving, which is one more reason the web archive, which you can fix, matters.

Part 5: The quiet failure mode, reference rot

Some links still "work" but no longer show what you linked to: the page is now a custom 404 returning 200, a redirect to a homepage, or an updated article that no longer says what you quoted. A Harvard study of legal citations found that more than 70% of URLs in the journals studied, and 50% of URLs in U.S. Supreme Court opinions, no longer produced the information originally cited (Zittrain, Albert & Lessig, Harvard Law Review Forum, 2014). Status-code checkers can't catch this. For your most important sources, open them by hand once in a while, and keep Wayback snapshots of anything you quote.

Part 6: A routine for busy writers

When	What	Time
Every issue	Pre-send click-through; save key sources to Wayback	2–5 min
Monthly	Check the last month's issues plus your welcome/about pages	10 min
Quarterly	Full archive crawl from the sitemap; fix top-traffic issues first	1 hour
After any domain or platform change	Old-URL list check; fix redirects	1 hour
Ongoing	Automated daily check of the archive site	0 min once set up

For the bigger picture of what to check daily, weekly and monthly on any site, see Automating Website Monitoring: What to Check Daily vs Weekly vs Monthly.

Automating the archive check

The quarterly crawl is the step that usually slips, because it's never urgent until a reader or sponsor points out a dead link.

Disclosure: I build Uchik, which can run that check daily for a newsletter's web archive. Uchik crawls the site every day and emails a report of broken outbound and internal links, broken images and redirect problems, showing the page where each one was found. The features page lists the checks and the sample report shows what a report looks like. Limits worth knowing, also covered in the FAQ: it checks the public web archive, not the emails in inboxes; it detects link rot, not reference rot; and it reads server-delivered HTML, so links added only by JavaScript may be missed; and the free plan covers one site. Google Search Console is still worth connecting for your archive's indexing and 404 reports. You can sign up for free.

Checklist

[ ] Pre-send click-through for every issue
[ ] Welcome email and "start here" page links checked monthly
[ ] Key sources saved to the Wayback Machine at publish time
[ ] Archive URL list pulled from the sitemap
[ ] Quarterly outbound link check; top-traffic issues and sponsor links fixed first
[ ] Dead links updated, pointed to archived copies, or removed
[ ] Custom domain redirects tested from old subdomain links
[ ] Platform migration: old-URL inventory, mapping, one-hop redirects, re-check
[ ] Internal "as I wrote" links use canonical URLs
[ ] Important sources spot-checked for reference rot

Your archive is the best case for subscribing. Keeping its links alive keeps that case strong.

Redirect Chains in Shopify After Changing Product Handles

Sandeep Singh — Sun, 18 Oct 2026 19:32:14 +0000

Shopify makes changing a product URL easy. Edit the URL handle, leave the redirect box ticked, save. The old address now forwards to the new one, and nothing appears broken.

Do that a few times over a product's life (a rename for SEO, a rebrand, a seasonal tweak, a typo fix) and something quieter happens. The redirects start pointing at other redirects. A shopper clicking a two-year-old Pinterest pin or email link goes from handle A to handle B to handle C before seeing the product. That's a redirect chain, and Shopify stores accumulate them without anyone noticing.

This guide explains how chains form in Shopify specifically, what they cost, and a safe process to find and flatten them.

How product handles and redirects work in Shopify

Every product has a handle, the last part of its URL: /products/trail-runner-4. Shopify generates it from the product title when you create the product. You can edit it in the product's Search engine listing section.

When you change a handle in the admin, Shopify offers a "Create a URL redirect" checkbox so the old URL forwards to the new one, as described in a Shopify Community answer. The redirect appears in Content → Menus → View URL redirects, alongside any you create manually (Shopify Help: URL redirects).

Shopify's own product help includes a caution worth repeating: you can edit the handle, "but don't edit it too often or the product might not display in search engine results" (Shopify Help: Adding and updating products).

Three rules from Shopify's redirect documentation explain most of the surprises store owners run into:

Redirects only work from broken URLs. "You can redirect only from broken URLs… If the URL still loads a valid webpage, then the URL redirect won't work."
Reactivating content deletes redirects. If a hidden collection is made visible again, "the URL redirect is automatically deleted because redirects only work for URLs that return 404 errors". Shopify notes the same behaviour applies to products set to Draft or removed from sales channels.
301s are cached. "301 redirects are cached by browsers and search engines. If you remove a redirect after customers have accessed it, then the redirect might continue to work in their browsers until the cache expires."

How a chain forms

Here's a typical product history:

Date	Change	Redirects in admin
Jan	Created as `/products/trail-shoe`	none
Apr	Renamed for SEO → `/products/waterproof-trail-running-shoe`	`trail-shoe` → `waterproof-trail-running-shoe`
Sep	New version, renamed → `/products/trail-runner-4`	`waterproof-trail-running-shoe` → `trail-runner-4`

Now anyone following an old link to /products/trail-shoe goes:

/products/trail-shoe  →301→  /products/waterproof-trail-running-shoe  →301→  /products/trail-runner-4

Two hops. Add a domain change (http:// → https://, or the myshopify.com domain → your custom domain) or a www redirect in front, and it's three or four.

Other common ways chains appear in Shopify:

Imported redirects from a previous platform that point at URLs you later changed again
Redirect apps layering their own rules on top of the native redirect list
Collection handle changes where internal links, menus or old redirects still use the older handle
Old campaign redirects (/spring-sale → a collection) whose target collection was later renamed

Why chains matter

Speed

Each redirect is another round trip before the page can load. Lighthouse notes that a redirect "can delay the loading of the resource by hundreds of milliseconds" and fails a page that has two or more redirects (Lighthouse: Avoid multiple page redirects). web.dev's LCP guide adds that a common cause of slow Time to First Byte "for an otherwise fast site is visitors arriving through multiple redirects, such as from advertisements or shortened links" (Optimize LCP). Ads, emails and social posts are exactly where old product URLs live.

Fragility

Every link in a chain is a point of failure. If someone deletes or edits the middle redirect while tidying up, or the middle URL becomes a live page again (Shopify then deletes that redirect, per the rule above), the chain breaks. Old links then land on a 404 or the wrong page.

Search signals

Google follows redirects, and its documentation describes permanent redirects as a strong signal that the target should be canonical (Redirects and Google Search). Google can follow several hops, but there's no benefit in making it. Shorter paths are simpler for crawlers and leave fewer chances for something to go wrong.

Step 1: Export your redirect list

In Content → Menus → View URL redirects, use Export to download your redirects as CSV (Shopify Help). You'll get two columns: Redirect from and Redirect to. Save a copy before making changes; that's your rollback.

Step 2: Find chains in the export

A chain exists wherever a Redirect to value also appears as a Redirect from value. A short script finds them and calculates each URL's final destination:

import csv

rows = list(csv.DictReader(open("redirects.csv", newline="", encoding="utf-8")))
# Adjust these names to match your export's header row
src_col, dst_col = "Redirect from", "Redirect to"
m = {r[src_col].strip(): r[dst_col].strip() for r in rows}

def resolve(path, seen=None):
    seen = seen or []
    if path in seen:
        return None, seen + [path]          # loop
    if path not in m:
        return path, seen
    return resolve(m[path], seen + [path])

for src in m:
    final, path = resolve(src)
    if final is None:
        print("LOOP:", " -> ".join(path))
    elif len(path) > 1:
        print(f"CHAIN ({len(path)} hops): {' -> '.join(path)} -> {final}")

This covers your native redirect list. It won't see redirects from apps or domain-level rules, so verify live URLs too.

Step 3: Verify against the live store

Check what visitors actually experience, including domain and protocol hops:

while read -r url; do
  curl -s -o /dev/null -L -w "%{num_redirects} hops  %{http_code}  %{url_effective}  <- $url\n" "$url"
done < old-urls.txt

Build old-urls.txt from the Redirect from paths (with your domain added), plus a few old links from emails, ads and social posts. Anything with more than one hop, or ending in a 404, needs attention.

Step 4: Flatten the chains

For each chain, edit the first redirect (and every intermediate one) so it points straight at the final URL:

Redirect from	Before	After
`/products/trail-shoe`	`/products/waterproof-trail-running-shoe`	`/products/trail-runner-4`
`/products/waterproof-trail-running-shoe`	`/products/trail-runner-4`	`/products/trail-runner-4` (unchanged)

Keep the intermediate redirects. Other links may point at the middle URL, and it still needs to resolve, just in one hop. Shopify lets you edit redirects one at a time or in bulk, and import a corrected CSV (Shopify Help). For bulk changes, test the import on a handful of rows first.

Loops (A → B → A) are urgent: those URLs fail outright. Decide the correct final page and point both at it.

Step 5: Update your own links

Redirects exist for links you can't change. For links you can, point straight at the current URL:

Navigation menus and footer links
Homepage sections, banners and featured product blocks
Collection descriptions and blog posts
Email templates, automations and saved campaign links
Ads, social profile links and anything in your own control

A crawl of your storefront will list internal links that pass through redirects. Fix those at the source and only old external links will ever touch a redirect.

Step 6: Change handles less often, and more deliberately

Decide the handle at launch. Short, descriptive, stable, without years or version numbers unless the product genuinely is versioned.
Don't rename for small SEO tweaks. Shopify's own warning about editing handles too often applies. Improve the page title and description instead; those don't change the URL.
When you must rename, tick the redirect box, then immediately check whether the old handle was itself the target of an earlier redirect, and repoint that.
Successor products: for a genuinely new model, consider a new product with its own URL, and redirect the old product to it only when the old one is retired. I covered those decisions in Product Page 404s and Out-of-Stock URLs: An Ecommerce Guide.

Step 7: Recheck regularly

Chains come back as the catalogue evolves. A quarterly export-and-script check, plus a crawl after any bulk catalogue change, keeps them under control. For the broader Shopify link clean-up, including broken links and missing images, see How to Find and Fix Broken Links on a Shopify Store.

Disclosure: I build Uchik, which can automate the crawling part. Uchik checks your store every day with read-only GET requests (it never adds to cart or places orders) and emails a report of broken links, missing images and redirect problems, each tied to the page and HTML element where the link appears. How it works explains how it follows redirects one hop at a time and records each hop; the features page lists the checks and the sample report shows a redirect finding. Two honest limits: its redirect-chain warning is aimed at longer chains (more than three hops), so the export-and-script check above is still the best way to catch two-hop chains in your redirect list. It also reads server-delivered HTML, so links added only by JavaScript or apps may be missed. It isn't a Shopify app; it checks your public pages from outside. You can sign up for free.

Checklist

[ ] Redirect list exported and backed up
[ ] Chains and loops found with a script
[ ] Old URLs (including emails, ads, social) tested live for hop count
[ ] Every redirect points straight at the final URL; intermediates kept
[ ] Loops fixed first
[ ] Menus, banners, collections, blog posts and email templates link to current URLs
[ ] Handle changes rare and deliberate; redirect box ticked and earlier redirects repointed
[ ] Quarterly recheck and a crawl after bulk catalogue changes

One redirect is good housekeeping. Three in a row is housekeeping that needs doing again.

HTTPS and Mixed Content on WordPress After Installing SSL

Sandeep Singh — Sun, 18 Oct 2026 19:22:40 +0000

You installed the SSL certificate. Your host says it's active. You visit the site and... the padlock is missing, or the browser warns that parts of the page aren't secure, or some images have vanished, or the slider stopped working. Welcome to mixed content, the most common problem after moving a WordPress site to HTTPS.

It matters beyond looks. Browsers block some insecure resources outright, so features break. Visitors see warnings at exactly the moment you want them to trust you (contact forms, checkouts, sign-ups). And Google's page experience guidance asks whether "your pages are served in a secure fashion" (Understanding page experience).

This guide covers switching WordPress to HTTPS properly, finding every source of mixed content, and making sure it doesn't creep back.

What mixed content is, and why some of it breaks your site

Mixed content means an HTTPS page loads a sub-resource (image, script, stylesheet, iframe, font) over plain HTTP. MDN explains that browsers now split it into two categories (MDN: Mixed content):

Upgradable content: browsers "should automatically upgrade requests" from HTTP to HTTPS. This includes <img> with a src attribute, CSS images like background-image, and audio and video. If the file exists at the HTTPS address it loads; if not, you get a missing image.
Blockable content: everything else, including scripts, stylesheets, iframes and fonts, which browsers block.

Two details catch WordPress sites out:

Images loaded through srcset or <picture> are not in the upgradable list, according to MDN. WordPress uses srcset for responsive images, so old http:// image URLs in srcset can break even when the plain src would have been upgraded.
Resources requested from an IP address rather than a hostname aren't upgraded either.

So mixed content produces three kinds of symptoms: a missing padlock or warning, missing images, and broken features where a script, stylesheet or embed was blocked.

Step 1: Make sure HTTPS itself works

Before touching WordPress settings:

Visit https://yourdomain.com directly. The certificate should be valid for both the www and non-www names you use.
Check the certificate's expiry and that renewal is automatic. Let's Encrypt certificates, which many hosts use, last 90 days by default and are meant to renew automatically (Let's Encrypt FAQ).
If you're behind Cloudflare or another proxy, check its SSL mode. A proxy in "Flexible" mode talking to the origin over HTTP while WordPress forces HTTPS is a classic cause of redirect loops.

Step 2: Switch WordPress's own URLs to HTTPS

WordPress stores two URLs in Settings → General: "WordPress Address (URL)" and "Site Address (URL)". Both need to start with https://.

Since WordPress 5.7, Site Health can do this for you. WordPress detects whether the environment supports HTTPS and, if so, shows a button in the HTTPS section of Tools → Site Health that "switches the site from HTTP to HTTPS with a single click" (Make WordPress Core: HTTPS in WordPress 5.7). The underlying function also verifies the change worked and reverts it automatically if WordPress doesn't then recognise the site as HTTPS.

The same release added on-the-fly rewriting of insecure references to your own site's URL in content. That rewriting only applies when certain conditions are met: the site uses HTTPS, the Site Address and WordPress Address use the same domain, and an internal migration flag was set because the URLs were switched on a site with existing content. It's a big help, but it rewrites output rather than fixing the stored data. It also doesn't cover every place a URL can hide: theme files, CSS, third-party embeds, and plugins that build their own output. The core announcement itself notes that advanced configurations aren't supported by the one-click migration.

To force HTTPS in the dashboard, WordPress's documentation describes setting FORCE_SSL_ADMIN in wp-config.php (WordPress: HTTPS):

define( 'FORCE_SSL_ADMIN', true );

Step 3: Redirect all HTTP traffic to HTTPS

Every http:// URL should 301-redirect to its https:// equivalent in one hop, with no chain through http://www → https://www → https://. Many hosts offer a "force HTTPS" toggle; otherwise use a server rule. Check with:

curl -sIL http://example.com/some-page/ | grep -iE "^(HTTP|location)"

You want exactly one 301 and then a 200. Google's site move documentation notes that an HTTP-to-HTTPS move doesn't need the Change of Address tool, but the redirects themselves are essential (Site moves with URL changes).

Step 4: Fix the stored URLs in the database

Old posts, pages, widgets, menus, custom fields and plugin settings often contain hard-coded http://yourdomain.com/... links and image URLs. Fixing them in the database makes the fix permanent rather than relying on output rewriting.

With WP-CLI (take a backup first):

wp db export before-https.sql
wp search-replace 'http://example.com' 'https://example.com' --dry-run
# check the counts, then run without --dry-run
wp search-replace 'http://example.com' 'https://example.com'

WP-CLI's documentation notes that search-replace "intelligently handles PHP serialized data", which is why it's safer than raw SQL for WordPress options and widgets (WP-CLI: search-replace). Repeat for http://www.example.com if your old content used it. Many hosts and migration plugins offer an equivalent tool if you don't have shell access.

Step 5: Hunt down what's left

After the database fix, remaining mixed content usually comes from:

Theme files: hard-coded http:// in header.php, footer.php or template parts. Search the theme folder for http://.
CSS files: background-image: url(http://...) in theme or custom CSS, including the Customizer's "Additional CSS".
Page builder data: some builders store CSS or URLs in their own tables or files; regenerate their CSS after the database change if they offer that option.
Third-party embeds: old video, map, form or widget embed codes using http://. Replace them with the provider's current HTTPS embed code.
External images: images hotlinked from other sites over HTTP. If the other site doesn't support HTTPS, host the image yourself.
Plugin settings: logo URLs, tracking scripts and custom code fields in plugins.
Hard-coded IP addresses: these aren't upgraded by browsers at all.

How to find them

Browser developer tools: open the Console on a page; browsers log mixed content warnings and blocked requests with the exact URL.
View source and search for http://.
Crawl the site: a crawler that reports insecure resources finds mixed content across all pages, not just the ones you thought to check. Screaming Frog's free version (up to 500 URLs; limits) can flag HTTP links and insecure resources found on HTTPS pages, with the page each one appears on.

WordPress-specific gotchas

A few situations trip people up even after following the steps above:

Greyed-out URL fields. If "WordPress Address" and "Site Address" can't be edited in Settings, they're probably defined as WP_HOME and WP_SITEURL constants in wp-config.php. Change them there instead.
Caching. Page caches, CDN caches and minified CSS bundles can keep serving the old http:// versions for hours or days. Clear every cache layer after the switch, including any your host runs.
Multisite. Each site in a network has its own URLs, and the one-click migration doesn't support every advanced configuration. Plan the change per site.
Email and form links. Transactional email templates and form confirmation messages often contain hard-coded links. Search plugin settings, not just posts.

Step 6: Lock it in (optional, carefully)

Two headers can stop regressions, but both need care:

Content-Security-Policy: upgrade-insecure-requests tells browsers to request all of the page's HTTP sub-resources over HTTPS (MDN: upgrade-insecure-requests). It's a useful safety net, but it hides problems rather than fixing them, and a resource with no HTTPS version still fails.
Strict-Transport-Security (HSTS) tells browsers to only use HTTPS for your domain for a period set by max-age (MDN: Strict-Transport-Security). Start with a short max-age and only extend it, or add includeSubDomains or preload, once you're sure every subdomain supports HTTPS. Mistakes here are hard to undo.

Step 7: Re-check, then keep checking

After the switch:

Crawl the site again; there should be no HTTP resources on HTTPS pages and no internal links to http:// URLs.
Check canonical tags, og:image and sitemap URLs now use https://.
Look at Search Console over the following weeks for crawl errors or indexing drops.

Mixed content tends to come back: a new embed pasted into a post, a plugin that stores an http:// logo URL, an old page restored from a revision. That's why a recurring check matters more than a one-time cleanup. I covered the store-owner version of this, including broken images, in Mixed Content and Missing Images: A Practical Fix Guide for Store Owners. SSL renewal is one of the yearly items in The Website Maintenance Checklist for Small Business Websites.

Disclosure: I build Uchik, which can handle the "keep checking" part. Uchik crawls your site every day and emails a report that includes HTTPS mixed content alongside broken links, missing images and redirect chains, each tied to the page and HTML element to fix. The features page lists the checks, How it works explains the crawl, and the sample report shows a mixed-content finding. It reads server-delivered HTML, so resources added only by JavaScript may be missed; the browser console is still the final check for those. You can sign up for free.

Checklist

[ ] Certificate valid for all hostnames; auto-renewal confirmed
[ ] Proxy/CDN SSL mode compatible (no Flexible-mode loops)
[ ] WordPress Address and Site Address on https:// (Site Health one-click or Settings)
[ ] FORCE_SSL_ADMIN set
[ ] Single-hop 301 from every HTTP URL to HTTPS
[ ] Database search-replace done with backup and dry run
[ ] Theme files, CSS, page builder data, embeds, plugin settings checked
[ ] No srcset or IP-address resources over HTTP
[ ] Canonicals, og:image, sitemap on HTTPS
[ ] Optional: upgrade-insecure-requests; HSTS with a short max-age first
[ ] Recurring crawl for mixed content and HTTP links

The certificate is the easy part. Making every image, script and link on the site follow it is what earns the padlock.

The SEO Meta Tags Checklist: Title, Description, Canonical and Open Graph

Sandeep Singh — Sun, 18 Oct 2026 19:22:25 +0000

The <head> of a web page is easy to forget because visitors never see it. But it controls the headline people see in Google, the preview text under it, which URL search engines treat as the "real" version of a page, whether the page is indexed at all, and what appears when someone shares the link on social media or in a chat app.

When these tags are wrong, nothing visibly breaks. The page loads fine. You just get fewer clicks from search results, odd previews when people share your work, or pages that quietly drop out of the index. That's why they deserve a checklist and a regular audit.

This guide covers the tags that matter, what Google's documentation says about each, the common mistakes, and the tags you can stop worrying about.

The minimum viable `<head>`

Here's a sensible baseline for a typical content or product page:

<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Trail Runner 4 Waterproof Running Shoe | Example Outdoor</title>
  <meta name="description" content="Lightweight waterproof trail shoe with a grippy outsole. Free returns within 30 days. See sizes and colours.">
  <link rel="canonical" href="https://example.com/products/trail-runner-4">

  <meta property="og:title" content="Trail Runner 4 Waterproof Running Shoe">
  <meta property="og:type" content="product">
  <meta property="og:image" content="https://example.com/images/trail-runner-4-og.jpg">
  <meta property="og:url" content="https://example.com/products/trail-runner-4">
  <meta property="og:description" content="Lightweight waterproof trail shoe with a grippy outsole.">
</head>

Now the detail for each.

1. `<title>`: the most important tag here

The title element is usually the source of the clickable headline in Google results (Google calls it the "title link"). Google's guidance (Title links) boils down to:

Every page should have one. "Make sure every page on your site has a title specified in the <title> element."
Descriptive and concise. Avoid vague titles like "Home" or "Profile", and avoid "unnecessarily long or verbose text".
Unique per page. Google warns against "repeated or boilerplate text", giving the example that titling every page of a commerce site "Cheap products for sale" makes pages impossible to tell apart.
No keyword stuffing. "Foobar, foo bar, foobars, foo bars" style titles "can make your results look spammy".
Brand concisely. A short brand name at the start or end, separated by a delimiter, is fine.

Google may rewrite the title link it shows if it thinks another text on the page describes the page better, so a well-written, accurate title is your best way to influence it.

Common mistakes:

Every page using the site name as its title (template default never changed)
Duplicate titles across paginated, filtered or variant URLs
Titles that describe the old content after a page was rewritten
Missing titles on pages generated by plugins or apps

2. Meta description: your pitch, not a ranking factor

<meta name="description" content="...">

Google's snippet documentation is precise about this tag: snippets are "primarily created from the page content itself. However, Google sometimes uses the meta description HTML element if it might give users a more accurate description of the page" (Snippets). So it influences the text under your result rather than your ranking.

Google's guidance for good descriptions:

Unique per page, at least for the homepage and important pages.
Informative, not a list of keywords. Google gives a "bad" example of a keyword list and a "better" one that explains what the page offers.
No fixed length limit: "There's no limit on how long a meta description can be, but the snippet is truncated in Google Search results as needed, typically to fit the device width."

Generated descriptions are fine for large sites if they use page-specific data, such as a product's key attributes.

Common mistakes: the same description on every page; descriptions left from a template ("Just another WordPress site"); descriptions that promise something the page doesn't deliver.

3. Canonical: telling search engines which URL is the real one

<link rel="canonical" href="https://example.com/products/trail-runner-4">

The same content is often reachable at several URLs: with and without www, with tracking parameters, through filtered category paths, or as variants. The canonical tag says which one you prefer.

Google's documentation lists the ways to indicate a canonical "in order of how strongly they can influence canonicalization": redirects are "a strong signal", rel="canonical" link annotations are "a strong signal", and sitemap inclusion is "a weak signal". It notes these methods "can stack", becoming more effective when combined (Consolidate duplicate URLs). A canonical is a strong hint, not a command; Google may choose a different URL if other signals disagree.

Rules of thumb:

Use absolute URLs with the correct protocol and host.
Point to a URL that returns 200, not a redirect or a 404.
Self-reference on canonical pages (each page names itself).
Keep canonicals, internal links, redirects and sitemaps consistent. If they disagree, you're sending mixed signals.

Common mistakes:

Every page canonicalised to the homepage (a template bug that can effectively hide your whole site)
Canonicals pointing at the staging domain after launch
Canonicals to http:// after moving to HTTPS
Canonicals pointing at URLs that now 404 or redirect

4. Robots meta: indexing on or off

<meta name="robots" content="noindex">

You only need this tag when you want to restrict something, because the default is to index and follow. Google's documentation says that when it sees noindex, it will "drop that page entirely from Google Search results, regardless of whether other sites link to it", and it notes that the page must not be blocked by robots.txt or Google can't see the rule at all (Block Search indexing with noindex).

Audit for: noindex left on from staging, or applied by a plugin setting to templates you actually want indexed (tag pages, products, blog posts).

5. Viewport: required for mobile

<meta name="viewport" content="width=device-width, initial-scale=1">

Google describes this tag as telling "the browser how to render a page on a mobile device", adding that its presence "indicates to Google that the page is mobile friendly" (Meta tags Google supports). Most modern themes include it; check custom templates and landing page builders.

6. Open Graph: how your links look when shared

Open Graph tags control the title, image and description shown when a page is shared on many social networks and messaging apps. The Open Graph protocol lists four required properties for every page:

og:title: the title as it should appear
og:type: for example website, article, or other types
og:image: an image URL representing the page
og:url: the canonical URL, used as the page's permanent ID

og:description is optional but commonly used. Some platforms also read their own tags (for example, twitter:card for X); check each platform's documentation for current image size recommendations.

Open Graph tags aren't a Google ranking signal, but they affect click-through from shares, which is often a large source of traffic for blogs, newsletters and stores.

Common mistakes:

Broken og:image: the image was deleted or moved, so shares show a blank box
og:image using a relative URL or http:// on an HTTPS site
og:url different from the canonical
The same default image and title on every page

7. Tags you can drop or ignore

<meta name="keywords">: Google says it "is not used by Google Search, and it has no effect on indexing and ranking at all" (Meta tags Google supports). Harmless, but don't spend time on it.
Meta refresh redirects: Google recommends a server-side 301 redirect instead.
Duplicate tags: two titles, two descriptions or two canonicals (often from a theme and a plugin both adding them) send conflicting signals. Remove the duplicate.

How to audit meta tags across a site

Checking one page is easy: view source or use your browser's developer tools. Checking a whole site needs a crawler.

Screaming Frog SEO Spider (free up to 500 URLs; limits) has dedicated tabs for Page Titles, Meta Description and Canonicals, with filters for missing, duplicate and multiple tags.
Google Search Console: URL Inspection shows the canonical Google selected versus the one you declared, which is the best way to spot canonical conflicts. The Page indexing report lists pages excluded by noindex and pages marked "Duplicate, Google chose different canonical than user".
Quick one-page check from the terminal:

curl -sL https://example.com/page | grep -iE '<title|name="description"|rel="canonical"|name="robots"|property="og:'

Work through issues in this order: accidental noindex → missing or duplicate titles → wrong canonicals → missing descriptions on key pages → broken og:image → everything else.

For small personal sites and portfolios, SEO Health Basics for Personal Websites and Portfolios covers these checks alongside indexing and link health.

Keeping it right over time

Meta tags break silently over time: a new template ships without a canonical, a plugin update changes how descriptions are generated, a page is rewritten but keeps its old title, a CDN change breaks every og:image. A one-off audit is a good start; a recurring check is what keeps it right. The Website Maintenance Checklist for Small Business Websites puts this review in the yearly content pass, but on sites that change often, more frequent automated checks are worth it.

Disclosure: I build Uchik, which includes basic on-page checks in its daily crawl. Uchik emails a report that flags missing titles, meta descriptions, H1s and canonical tags, alongside broken links, missing images, redirect chains and mixed content, each tied to the exact page. The features page lists every check and How it works explains the crawl. It doesn't validate Open Graph tags or compare declared and Google-selected canonicals (use Search Console's URL Inspection for that), and it reads server-delivered HTML, so tags injected only by JavaScript may be missed. The FAQ covers other limits. You can sign up for free.

Checklist

[ ] <meta charset> and viewport present
[ ] Unique, descriptive, concise <title> on every page; no boilerplate
[ ] Unique, informative meta description on homepage and key pages
[ ] Self-referencing absolute canonical; points to a 200 URL
[ ] Canonicals, redirects, internal links and sitemap agree
[ ] No stray noindex; noindex pages not blocked in robots.txt
[ ] og:title, og:type, og:image, og:url on shareable pages; og:image loads over HTTPS
[ ] No duplicate title/description/canonical tags from theme + plugin
[ ] Meta keywords ignored; meta refresh replaced with 301s
[ ] Recurring audit scheduled or automated

Ten minutes in the <head> can decide whether people click, share and find the page in the first place.

Product Page 404s and Out-of-Stock URLs: An Ecommerce Guide

Sandeep Singh — Sun, 18 Oct 2026 19:16:19 +0000

Ecommerce catalogues change constantly. Products sell out, come back, get replaced by a new version, change names, move collections or disappear for good. Every one of those changes affects a URL, and every URL might be linked from somewhere: your own homepage banner, a collection page, a blog post, an email campaign, a supplier's site, a Pinterest pin, a Google Shopping listing, or a customer's bookmark.

Handle those changes badly and you get two kinds of loss:

Shoppers hit dead ends. Someone clicks "Shop the look" in last month's email and lands on a "Page not found". That's a lost sale, and they may not come back.
Search visibility leaks away. Product pages that ranked drop out of the index, and links pointing at them stop helping you.

Here's a practical decision guide for each situation, based on what Google has actually said, and a routine to catch broken product links before your customers do.

The four product URL situations

1. Temporarily out of stock (it's coming back)

Keep the page live, returning 200, and say clearly that it's out of stock.

Show the status prominently with an expected restock date if you know it.
Offer a "notify me when available" option and related in-stock alternatives.
Keep the product in your structured data, with availability set to out of stock. Google's Product structured data supports https://schema.org/OutOfStock and related values such as PreOrder and BackOrder (Product snippet structured data). Most ecommerce platforms update this automatically from inventory. Check yours does.
If you use Merchant Center, keep the feed's availability attribute in sync.

Google's John Mueller has said that sites can handle temporarily unavailable products in different ways (marking them out of stock, using a 404, or adding noindex) and that "all of those can work for search", including the approach of keeping the page as a 200 marked out of stock and making it a 404 later if the product doesn't return (Google SEO office hours, June 18, 2021). For most stores, keeping the page live is the most customer-friendly option, because people who arrive can sign up for a restock alert instead of hitting an error.

2. Permanently discontinued, with no direct replacement

Let the URL return a real 404 or 410, and remove internal links to it.

Google's Search Console help is direct: "If you have permanently deleted content without intending to replace it with newer, related content, let the old URL return a 404 or 410." It adds that Google currently treats 410 the same as 404 (404 errors).

Make the 404 page useful: search, top categories and bestsellers. You can return a 404 status code while showing whatever helpful content you like.

Small, high-effort catalogues are an exception. In a video on Google's official Search Central (formerly Google Webmasters) channel, Google suggested that for a handful of handmade, high-effort products it can be worth keeping the page and showing related items, while for larger catalogues with hundreds or thousands of products, returning a 404 for truly gone products is reasonable (What should sites do with pages for products that are no longer available?). If you keep the page, make it obvious the item is no longer available and show alternatives prominently.

3. Replaced by a new version or a close equivalent

301-redirect the old URL to the replacement product.

"Trail Runner 3" replaced by "Trail Runner 4" is a genuine successor, so a permanent redirect sends shoppers and search signals to the right place. Google's redirect documentation describes permanent redirects (301, 308) as a signal that the target should be shown in search results (Redirects and Google Search).

Redirect only to something a shopper looking for the old product would actually want. Redirecting to a related category can be reasonable when the category is clearly the right next step. Redirecting all discontinued products to the homepage is not.

4. URL changed (same product, new handle or slug)

Always 301 the old URL to the new one, in a single hop.

This is the most avoidable product 404. It happens when someone edits a product title and the platform regenerates the URL handle, or during a migration when URL patterns change. Most platforms have a redirect tool: Shopify's is under Content → Menus → View URL redirects, and redirects "start working immediately" (Shopify Help: URL redirects). Get in the habit of checking for a redirect every time a product URL changes.

The mistake to avoid: homepage catch-alls

Some stores, or apps installed on them, redirect every missing product URL to the homepage. It looks tidy but it's a known problem. Google's help page says that "redirecting users to another page, such as the homepage, instead of returning a 404" creates soft 404s, which "can be confusing to both users and search engines" (404 errors). A shopper who clicked a specific product and lands on your homepage has no idea what happened.

If you have a "redirect all 404s" setting or app, review it.

Where broken product links hide

The product page is only half the story. The links pointing to products break just as often:

Homepage banners and featured products pointing at items that sold out and were archived
Collection and category pages with manually added links
Blog posts and buying guides ("our 10 favourite…") written months ago
Navigation menus with hand-picked product links
Email campaigns and automations, such as abandoned-cart, win-back and welcome sequences, with hard-coded product URLs
Social posts, pins and influencer links you can't edit, but whose targets you can redirect
Product images referencing deleted files, leaving broken images on otherwise working pages

Fix your own links at the source. For links you can't edit (old emails, social posts, other sites), the redirect decisions above are what protect you.

A routine that catches problems early

Daily: automated crawl

Crawl the storefront daily for:

Internal links returning 404, especially from the homepage, menus and collections
Missing product and banner images
Redirect chains (old handle → older handle → current)
Links to cart and checkout URLs that fail

Use read-only crawling only. A crawler that clicks "Add to cart" or submits forms on a live store creates junk carts and orders.

Weekly: catalogue changes review

Before or after any batch of catalogue changes (seasonal range swaps, discontinued lines, renamed products):

Export the list of product URLs being removed or changed.
Decide for each: keep live (out of stock), 404, or 301 to a successor.
Add the redirects.
Search your own content (blog, menus, banners, email templates) for links to those URLs and update them.
Re-check the list after the change: each URL should be a single-hop 301, a deliberate 404, or a live page.

A quick list check from the command line:

while read -r url; do
  curl -s -o /dev/null -w "%{http_code} %{num_redirects} %{url_effective}  <- $url\n" -L "$url"
done < changed-products.txt

Monthly: Search Console

Check Indexing → Pages for spikes in "Not found (404)" and "Soft 404". A soft 404 spike after installing a redirect app is a strong hint that it's sending missing products to the homepage.

Images: the quieter version of the same problem

Missing images are the product-page equivalent of broken links: the page loads but looks broken, and shoppers trust it less. They usually come from deleted media files, CDN path changes in migrations, or theme changes that reference old image sizes. I covered finding and fixing them, including mixed-content images after an HTTPS change, in Mixed Content and Missing Images: A Practical Fix Guide for Store Owners. For the Shopify-specific steps to find and fix broken links, see How to Find and Fix Broken Links on a Shopify Store.

Decision table

Situation	Status code	Internal links	Structured data / feed
Out of stock, returning	200 (live page)	Keep; optionally de-emphasise	Availability = out of stock / backorder
Discontinued, no replacement	404 or 410	Remove	Remove product
Replaced by successor	301 → successor	Update to successor	Successor's data
URL/handle changed	301 → new URL (one hop)	Update to new URL	Update URL
Small catalogue, high-effort item gone	200 with clear "no longer available" + alternatives, or 404	Remove from listings	Remove offer

Automating the daily check

The daily crawl is the step that most stores skip, and it's where most of the lost sales come from: a dead link on the homepage can sit there for weeks.

Disclosure: I build Uchik, which focuses on exactly this. Uchik crawls your store every day with read-only GET requests (it never adds to cart, submits forms or places orders) and emails a report of broken product, collection, cart and checkout links, missing images and redirect chains, each with the page and HTML element that caused it. The features page lists the checks, the sample report includes an ecommerce example, and the FAQ covers the limits: links added only by JavaScript, such as some app-injected recommendation widgets, may be missed. It isn't a Shopify or WooCommerce app; it checks your public pages from outside. You can sign up for free.

Checklist

[ ] Out-of-stock products stay live with clear status and correct structured data
[ ] Discontinued products with no replacement return 404/410
[ ] Successor products get a single-hop 301
[ ] Every handle/slug change gets a redirect
[ ] No "redirect all 404s to homepage" setting or app
[ ] Banners, menus, collections, blog posts and email templates updated after catalogue changes
[ ] Daily read-only crawl for broken product links and images
[ ] Monthly Search Console check for 404 and soft 404 spikes

Every product URL is a promise to someone who saved it, shared it or clicked it in an email. Keeping those promises is cheaper than winning those shoppers back.

Broken Link Checking for Agencies Managing Client Sites

Sandeep Singh — Sun, 18 Oct 2026 19:15:45 +0000

If you look after one website, broken links are a chore. If you look after twenty, they're a process problem.

Agencies and freelancers who maintain client sites tend to discover broken links the worst possible way: the client finds them first. A "Book a consultation" button that has pointed to a deleted page for three weeks. A product range removed by the client's own team, still linked from the homepage banner. A PDF menu replaced with a new file name. The client emails, slightly annoyed, and asks why they're paying for maintenance.

The fix isn't working harder. It's having a system where every client site is checked on a schedule, problems are triaged by impact, and the client hears about issues from you, along with the fix, before they find them.

This guide sets out that system using free or low-cost tools. It's written for small agencies, freelancers and in-house teams who manage several sites.

Why agency sites break more than you'd expect

Client sites have several features that make link rot more likely than on sites you fully control:

Many editors. The client's staff, their marketing contractor and your team all edit content. Nobody sees the whole picture.
Third-party dependencies. Booking widgets, payment pages, embedded forms, affiliate links and partner sites change without telling anyone.
Seasonal and campaign content. Promotions end, landing pages get unpublished, and the links pointing to them stay.
Platform churn. Plugin updates, theme switches and migrations between hosts or platforms.
The web itself decays. Pew Research Center found that 38% of webpages that existed in 2013 were no longer accessible a decade later, and that 23% of news webpages contained at least one broken link (Pew Research Center, 2024). Any client site that links out will lose some of those links over time.

None of this is your fault, but under a maintenance agreement it's your problem.

Step 1: Build a client site inventory

Before you can check sites consistently you need one list that everyone on the team can see. For each client:

Field	Why
Primary domain and any alternate domains	So you check the right one and catch redirect issues
Platform (WordPress, Shopify, Webflow, custom…)	Determines how fixes are made
Critical paths	The 3–10 URLs that make money or generate leads: booking, checkout, contact, pricing, key landing pages
Who edits content	So you know who to ask when something changes
Your access level	CMS, hosting, DNS, Search Console
Maintenance scope	What you're contracted to fix, and what you only report
Reporting contact	Who receives reports and approves changes

The critical paths column matters most. It's what turns "your site has 47 broken links" into "your booking button is broken, and here are 46 minor issues".

Step 2: Get the right access, without sharing passwords

Google Search Console: ask the client to add you as a user rather than sharing their Google login. Search Console supports Owner, Full and Restricted users (Managing owners, users, and permissions). Full access is usually enough for monitoring and URL inspection.
CMS: your own named account with the minimum role you need, not a shared "admin" login. This also gives you an audit trail of who changed what.
Platform redirect tools: make sure your role can create redirects (Shopify URL redirects, a WordPress redirect plugin, server or CDN rules). Otherwise every fix needs a ticket.

When a client relationship ends, removing your named accounts is clean. Rotating a shared password is not.

Step 3: Schedule the checks

Daily: automated crawl of each site

Every site should be crawled automatically, ideally daily, and the results should reach you without anyone remembering to start a scan. Look for a tool or setup that:

Runs on a schedule without someone pressing a button
Reports where each broken link is (source page and the HTML element) as well as which URL failed. Without that, fixing takes far longer
Uses read-only requests, so it's safe on live stores and never submits forms or creates orders
Groups results per site, so each client's issues stay separate

Options range from desktop crawlers you schedule yourself to hosted services. Screaming Frog SEO Spider is the standard desktop crawler and is free up to 500 URLs per crawl (limits); scheduling and some integrations need the paid licence. WordPress-only teams sometimes use a plugin such as Broken Link Checker on each site, though plugins add load to the client's server and differ in how they handle external links.

Weekly: critical-path check by a person

Automated crawls catch broken links; they don't confirm a contact form actually delivers email or that a booking widget completes. Once a week, someone should run each client's critical paths by hand, or with a test mode the platform provides, especially after updates.

Monthly: Search Console review

For each client, look at Indexing → Pages for growing "Not found (404)" or "Server error (5xx)" counts, and Performance for sudden drops on key pages. Google's 404 guidance is a useful framing for clients: a URL that doesn't exist and returns 404 is normal, and "redirecting users to another page, such as the homepage, instead of returning a 404" creates soft 404s that confuse users and search engines (Search Console Help: 404 errors).

Step 4: Triage by impact, not by count

A raw report with hundreds of rows will overwhelm a client and waste your time. Sort every issue into one of four buckets:

Priority	What	Response
P1: Revenue/lead blocker	Broken link or image on a critical path (checkout, booking, contact, pricing, main nav)	Fix same day; tell the client it's fixed
P2: Important page broken	A ranking page, high-traffic post or page with backlinks now returns 404/5xx	Restore or 301 to the correct replacement within the week
P3: Internal hygiene	Internal links through redirect chains, broken links in old posts, missing images on low-traffic pages	Batch-fix monthly
P4: External rot	Outbound links to third-party pages that died	Batch-fix monthly or quarterly; replace or remove

Redirect chains belong in P3 rather than being ignored: each hop is an extra request, and Lighthouse notes a redirect can delay loading "by hundreds of milliseconds" (Lighthouse: Avoid multiple page redirects).

Agree these definitions with clients up front, ideally in the maintenance agreement, so "we fix P1 same day" is a promise you can keep and report on.

Step 5: Fix at the source, and redirect only when it makes sense

Internal link broken: edit the link where it appears (page, menu, widget, template). Don't paper over it with a redirect.
Page moved or renamed: add a single-hop 301 from the old URL to the new one, so external links and bookmarks still work, and update internal links too.
Page deliberately removed: let it return 404 or 410 and remove internal links to it. Google treats 410 the same as 404 (Search Console Help).
Never redirect everything to the homepage. It's the soft 404 pattern Google warns against.

I covered the platform-specific mechanics for one common case in How to Find and Fix Broken Links on a Shopify Store.

Step 6: Handle the breakages clients cause

A large share of breakage on client sites comes from the client's own edits. That's fine; it's their site. But it needs handling diplomatically:

Report without blame: "On Tuesday the 'Spring offers' page was unpublished. Three pages still link to it, including the homepage banner. We've pointed them to the current offers page." That's a service, not an accusation.
Teach the pattern once: a short note for client editors: "before you delete or rename a page, tell us or add a redirect".
Offer a pre-change check: for planned redesigns or product range changes, crawl before and after.

Step 7: Report in the client's language

Clients don't care about status codes. A monthly report that works:

Headline: "All critical paths working" or "1 critical issue found and fixed on [date]".
What was fixed: counts by priority, plus examples of the P1/P2 fixes.
What needs a decision: e.g., "the supplier's catalogue page we link to is gone; should we remove the link or link to their homepage?"
Trend: issues found vs fixed over time. A falling line is the best evidence your maintenance is working.

For smaller clients, The Website Maintenance Checklist for Small Business Websites is a plain-English summary you can share so they understand what you're doing and why.

Common mistakes

Checking only when something feels wrong. Problems sit unnoticed for weeks.
Sending raw crawler exports to clients. Triage first.
Treating every 404 as urgent. Old, unlinked URLs returning 404 are normal.
Fixing with redirects instead of updating links. Chains build up over time.
Forgetting images. A missing hero image on a landing page is as visible as a broken link.
Relying on a plugin on every site without checking its load and update status across your portfolio.

Where automation fits

The daily crawl is the part that's most worth automating across a portfolio, because it's the part people skip when they're busy with client work.

Disclosure: I build Uchik, which handles that daily layer. Uchik crawls a site every day with read-only GET requests (it never submits forms or places orders) and emails a report where each broken link, missing image, redirect chain or mixed-content warning is tied to the page and HTML element that caused it, which makes P1 triage fast. How it works describes the crawl, the features page lists the checks, and the sample report shows what a client-ready report looks like. Limits worth knowing: it reads server-delivered HTML, so links added only by JavaScript may be missed, and it doesn't test that forms deliver. The free plan covers one website, so you can try it on one client before deciding. You can sign up for free.

Agency checklist

[ ] Client inventory with critical paths, editors, access and scope
[ ] Named accounts (CMS, Search Console) instead of shared logins
[ ] Daily automated crawl per site, with source-page detail
[ ] Weekly human check of critical paths and forms
[ ] Monthly Search Console review per client
[ ] P1–P4 triage rules agreed in the maintenance agreement
[ ] Fix-at-source policy; single-hop redirects; no homepage catch-alls
[ ] Monthly client report in plain language
[ ] Pre/post crawl around client-led changes

A broken link the client finds is a complaint. A broken link you found, fixed and reported is the reason they renew.

Automating Website Monitoring: What to Check Daily vs Weekly vs Monthly

Sandeep Singh — Sun, 18 Oct 2026 15:59:46 +0000

Most websites aren't monitored at all. Or they're "monitored" by whoever happens to notice something odd, which usually means a customer emailing to say the checkout doesn't work, a week after it stopped working.

The opposite problem is just as real. Teams that set up alerts for everything soon learn to ignore them, and an ignored alert is no better than no alert.

The fix is a schedule that matches the frequency of each check to two questions:

How fast can this break?
How much does it cost while it's broken?

A site going completely down can happen any minute and costs everything while it lasts, so you check it constantly. A domain renewal can only fail once a year and gives you weeks of warning, so you check it monthly. Everything else sits somewhere in between.

Here's a practical schedule for a small business, blog, store or SaaS marketing site, with what to automate at each level and a few small scripts to get started.

Continuous (every few minutes): is it up?

What: Does the homepage, and your most important page (checkout, booking, sign-up, login), return a 200 quickly?

Why this often: An outage is total. Every minute down means every visitor is lost, and it can happen at any time from a host failure, a bad deploy, an expired certificate or a DNS mistake.

How to automate: An uptime monitoring service that requests a URL every few minutes from outside your network and alerts you (email, SMS, chat) when it fails. Many offer free tiers for a handful of URLs. Check that the monitor:

Checks from outside your hosting provider (a monitor on the same server goes down with it)
Looks for expected text on the page, not just a status code, because an error page can still return 200
Requires a couple of consecutive failures before alerting, to avoid false alarms

Keep this list short: two to five URLs. This level is for "the site is down", not for every page.

Daily: is anything broken?

These are problems that don't take the site down but quietly cost visitors and sales. They can appear at any time (after an update, a content edit, a third-party change), and every day they go unnoticed costs you.

Broken links and missing images

Pages get edited, products get removed, external sites change, and links break. A daily crawl catches a broken "Buy now" button the day after someone deletes a product, not at the end of the quarter.

What to check:

Internal links returning 4xx/5xx
Missing images (404s on <img> sources)
New redirect chains or loops
Links to key conversion pages (cart, checkout, booking, pricing, contact) still resolving

I walked through doing this by hand for one platform in How to Find and Fix Broken Links on a Shopify Store. The daily version is the same checks, automated.

Certificate validity

Certificates are meant to renew automatically, but renewals do fail. Let's Encrypt certificates are valid for 90 days by default, and renewal is recommended every 60 days (Let's Encrypt FAQ). A daily check that warns when fewer than about 20 days remain gives you plenty of time to fix a stuck renewal:

#!/usr/bin/env bash
# cert-check.sh: warn if a certificate expires within N days
host="${1:?usage: cert-check.sh example.com [days]}"; days="${2:-20}"
cert=$(echo | openssl s_client -servername "$host" -connect "$host:443" 2>/dev/null)
end=$(openssl x509 -noout -enddate <<<"$cert" | cut -d= -f2)
if ! openssl x509 -noout -checkend $((days*86400)) <<<"$cert" >/dev/null; then
  echo "WARNING: $host certificate expires $end"; exit 1
fi
echo "OK: $host certificate valid until $end"

Backups completed

Not "are backups configured", but "did last night's backup finish?" Most backup tools can email on failure. Make sure that's turned on and goes to someone who reads it.

Key-page smoke test

A tiny script that requests your critical URLs and checks for the expected content:

#!/usr/bin/env bash
# smoke.sh: each line of urls.txt is "<url> <text that must appear>"
fail=0
while read -r url expect; do
  body=$(curl -sL --max-time 20 -w '\n%{http_code}' "$url")
  code=$(tail -n1 <<<"$body")
  if [[ "$code" != "200" ]] || ! grep -q "$expect" <<<"$body"; then
    echo "FAIL $code $url (missing: $expect)"; fail=1
  fi
done < urls.txt
exit $fail

One caution: don't automate form submissions or test purchases on a live site unless your platform provides a proper test mode. You'll fill your CRM with junk, trigger real emails or create real orders. Test forms by hand (weekly, below).

Running it on a schedule

Any scheduler works: cron on a server you control, your host's scheduled tasks, or a CI service. With GitHub Actions, for example:

name: daily-site-checks
on:
  schedule:
    - cron: "0 10 * * *"   # 10:00 UTC daily
  workflow_dispatch:
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: bash smoke.sh && bash cert-check.sh example.com

GitHub's documentation notes that scheduled workflows run on the default branch, can be delayed during periods of high load (particularly at the start of each hour), and in public repositories are automatically disabled after 60 days without repository activity (Events that trigger workflows). Pick an odd minute, and don't rely on this alone for time-critical alerts.

Weekly: the human checks

Some things need a person, or are slow-moving enough that weekly is fine.

Test every contact path by hand: submit the contact form, try the booking flow, tap the phone link on mobile. Contact forms often fail silently after plugin updates or email configuration changes.
Apply updates (CMS core, plugins, themes, dependencies), then re-run the daily checks and re-test forms.
Glance at Google Search Console. It emails about new critical issues, but a weekly look at Indexing → Pages for rising 404 or server-error counts catches slower trends.
Read the week's daily reports and fix anything still open.

Monthly: performance, content and access

Core Web Vitals. Search Console's Core Web Vitals report "shows how your pages perform, based on real world usage data" (Core Web Vitals report). Because it reflects real visitors over time, it moves slowly, so monthly is the right cadence. Google's targets are LCP within 2.5 s, INP under 200 ms and CLS under 0.1 (Core Web Vitals). Use PageSpeed Insights to diagnose any template that's slipping.
Content accuracy: prices, hours, staff, service areas, promotions that should have ended.
Outbound links on your most-visited pages, opened by hand, to check they still say what you linked them for. A status-code checker can't tell when a page changed content.
Access review: remove accounts for people who no longer need them (CMS, hosting, registrar, analytics).
Business listings: check that the website URL on your Google Business Profile and other directories still points at a working page.

Yearly: renewals and recovery

Domain renewal. Registrars of generic top-level domains must send at least two expiry reminders, about one month and about one week before expiry, under ICANN's Expired Registration Recovery Policy. That only helps if the contact email is current. Turn on auto-renew and confirm the payment card.
Restore test: restore a backup somewhere safe and confirm the site works.
Documentation: who owns the domain, hosting, DNS, email and each account, and when each renews.
Accessibility and SEO review of key templates.

For a non-technical version of this list, see The Website Maintenance Checklist for Small Business Websites.

Alerts versus reports

One last design decision makes the difference between monitoring people use and monitoring they mute:

Alerts (immediate, interruptive) are only for things that need action now: site down, checkout down, certificate expiring within days.
Reports (daily or weekly digests) are for everything else: broken links, missing images, redirect chains, slow templates. Nobody needs a 2 a.m. page about a broken link in a blog post from 2021, but they do need to see it in tomorrow's report.

If an alert fires and the right response is "I'll look at it later", it should have been a report.

Disclosure: I build Uchik, which handles the daily report layer. Uchik crawls your site once a day with read-only requests (it never submits forms or places orders) and emails a report of broken links, missing images, redirect chains, mixed content and basic SEO gaps, each tied to the exact page and HTML element. How it works explains the crawl, the features page lists the checks, and the sample report shows what arrives in your inbox. It isn't an uptime monitor and it doesn't measure Core Web Vitals, so pair it with the continuous and monthly checks above. Links added only by JavaScript may be missed. You can sign up for free.

The schedule on one page

Cadence	Check	Automate?
Every few minutes	Homepage + critical page up, expected text present	Yes: uptime monitor
Daily	Broken links, missing images, redirects	Yes: crawler
Daily	Certificate expiry > ~20 days	Yes: script or monitor
Daily	Backup succeeded	Yes: backup tool alerts
Daily	Critical URLs return expected content	Yes: smoke script
Weekly	Forms, booking, phone links	No: test by hand
Weekly	Updates applied, then re-tested	Partly
Weekly	Search Console indexing trends	Email alerts + quick look
Monthly	Core Web Vitals (field data)	Report; review by hand
Monthly	Content accuracy, outbound links, access, listings	No
Yearly	Domain renewal, restore test, documentation	Auto-renew + calendar

Start with the first two rows this week. Together they cover most of what quietly costs small sites visitors and sales.

Broken Links and Core Web Vitals: What Actually Affects Rankings

Sandeep Singh — Sun, 18 Oct 2026 15:59:30 +0000

Ask in any web forum whether broken links hurt SEO and you'll get confident answers in every direction. "Every 404 is a ranking penalty." "Google doesn't care about 404s at all." "Fix your Core Web Vitals or you'll never rank." "Core Web Vitals don't matter."

Most of these are partly true and mostly unhelpful. This article sticks to what Google's own documentation says, quotes it directly, and separates three different questions that usually get blurred together:

Do broken links affect rankings?
Do Core Web Vitals affect rankings?
What do both cost you regardless of rankings?

That third question is the one people skip, and it's often where the real losses are.

Part 1: What Google says about 404s and broken links

A 404 on its own is not a penalty

Google's Search Central blog answers this directly: "404 errors are a perfectly normal part of the web", and "If some URLs on your site 404, this fact alone does not hurt you or count against you in Google's search results." It goes further: the fact that some URLs return 404 "does not affect how your site's other URLs (the ones that return 200 (Success) status codes) perform in our search results" (Do 404 errors hurt my site?).

Google actually prefers a proper 404 or 410 for content you've removed, rather than a fake success page.

But a 404 on a page that matters is a real loss

The same post adds the important caveat: "if some of the pages that 404 are pages you actually care about, you should look into why." And Google's HTTP status documentation explains what happens to an indexed page that starts returning 4xx: "the indexing pipeline removes the URL from the index if it was previously indexed" (HTTP status codes).

So:

A random old URL returning 404 → normal, no penalty.
Your ranking product page, service page or popular post returning 404 → it drops out of search results. That isn't a "penalty", but the effect on your traffic is the same.

Internal links are how Google finds your pages

Broken internal links matter for a different reason: discovery. Google's link guidance says links are used to find new pages to crawl, and that "every page you care about should have a link from at least one other page on your site" (Link best practices). If the only link to a page is broken, or points through a JavaScript handler instead of a real <a href>, that page is harder for Google to discover.

Soft 404s and homepage redirects are worse than honest 404s

Google warns about two patterns: serving a "not found" page with a 200 status, and redirecting "any unknown URLs to their home page instead of returning 404 errors". Both "can have negative effects on our understanding and indexing" of your site (Do 404 errors hurt my site?).

Broken outbound links

I couldn't find any Google documentation saying broken links to other sites lower your rankings, so I won't claim they do. What they clearly do is make your content less useful and less trustworthy to readers, which is a good enough reason to fix them.

Part 2: What Google says about Core Web Vitals

The metrics and thresholds

Google's documentation defines three Core Web Vitals and the targets for a good experience (Core Web Vitals):

Metric	Measures	Good
Largest Contentful Paint (LCP)	Loading	within 2.5 seconds
Interaction to Next Paint (INP)	Responsiveness	less than 200 milliseconds
Cumulative Layout Shift (CLS)	Visual stability	less than 0.1

web.dev adds how these are assessed: a good threshold to measure is "the 75th percentile of page loads, segmented across mobile and desktop devices" (Web Vitals). In other words, most of your real visitors need a good experience, not just the developer on fast office Wi-Fi.

Yes, they're used in ranking, but they aren't decisive

Google's page experience documentation says: "Core Web Vitals are used by our ranking systems." In the same section it adds two important qualifications:

"Getting good results in reports like Search Console's Core Web Vitals report or third-party tools doesn't guarantee that your pages will rank at the top of Google Search results."
"Google Search always seeks to show the most relevant content, even if the page experience is sub-par. But for many queries, there is lots of helpful content available. Having a great page experience can contribute to success in Search, in such cases."

(Understanding page experience)

So the accurate summary is that Core Web Vitals are a real signal that can make a difference when competing pages are similarly relevant. They won't make an unhelpful page rank, and chasing a perfect score isn't worthwhile. Google says there is "no single signal" for page experience.

Lab scores versus field data

Lighthouse and PageSpeed Insights' lab results are diagnostic tools: one simulated load, on one simulated device. Search Console's Core Web Vitals report is different: it "shows how your pages perform, based on real world usage data (sometimes called field data)" (Core Web Vitals report). If you want to know how real visitors experience your site, the field data is what counts. Use Lighthouse to find out why.

The rest of page experience

Google's page experience page lists more than Core Web Vitals. It asks whether pages are "served in a secure fashion", display well on mobile, avoid excessive distracting ads and intrusive interstitials, and make the main content easy to distinguish. That "secure fashion" point is where HTTPS problems like mixed content come in. I covered fixing those in Mixed Content and Missing Images: A Practical Fix Guide for Store Owners.

Part 3: Where broken links and Core Web Vitals overlap

They're usually discussed separately, but several "link health" problems are also performance problems:

Redirect chains slow every page load

Every redirect is another network round trip before the page can even start loading. Lighthouse says this "can delay the loading of the resource by hundreds of milliseconds" and fails a page with two or more redirects (Avoid multiple page redirects). web.dev's LCP guide makes the connection explicit: Time to First Byte includes redirect time, a high TTFB "can make achieving a 2.5 second LCP challenging, or even impossible", and "a common cause of a slow TTFB for an otherwise fast site is visitors arriving through multiple redirects" (Optimize LCP). Visitors arriving from old internal links, ads or emails pay that cost. Updating internal links to point directly at final URLs is both a link fix and a speed fix.

Images without dimensions cause layout shift

web.dev lists "images without dimensions" first among the most common causes of poor CLS (Optimize CLS). Broken image references and slow-loading images often come together on older templates, so when you're fixing missing images, add width and height attributes (or CSS aspect-ratio) at the same time.

Broken resources waste requests

A page that requests a missing script, stylesheet, font or image still makes the request and waits for the 404. Removing references to resources that no longer exist is free performance.

Part 4: The costs that have nothing to do with rankings

Even where Google says something "does not hurt you" in search, it can still cost you:

A visitor who hits a 404 on a product, booking or sign-up page is a lost conversion today, whatever your rankings are.
A slow or jumpy page frustrates visitors who already found you. Core Web Vitals exist because these metrics reflect real user experience.
Broken links in content make readers trust your recommendations less.
Links from other sites to your dead pages stop sending referral visitors.

This is the strongest argument for fixing link problems: not that Google punishes them, but that people do.

Part 5: A sensible priority order

Based on all of the above, here's how I'd prioritise:

Important pages returning errors. Ranking pages, money pages and pages with backlinks that return 404/5xx. Restore them or 301 them to the correct replacement. (Direct loss of indexing and conversions.)
Broken internal links to live content. Fix at the source. (Discovery and user experience.)
Homepage-redirect catch-alls and soft 404s. Return honest 404s or targeted redirects. (Google explicitly warns about these.)
Redirect chains in internal links and navigation. Point links at final URLs. (Speed and crawl efficiency.)
Core Web Vitals issues in field data, starting with templates that affect many pages. (A ranking signal and a user-experience issue.)
Mixed content and HTTPS problems. (Part of page experience, plus browser warnings.)
Broken outbound links. (Trust and usefulness.)
Old, unlinked URLs returning 404. Usually nothing to do. That's normal.

Part 6: Monitoring both

The tools are complementary:

Search Console: Page indexing (404s Google sees), Core Web Vitals (field data), HTTPS report.
PageSpeed Insights / Lighthouse: diagnose why a page is slow.
A crawler (Screaming Frog's free tier handles up to 500 URLs; limits): every broken link, redirect and missing image, with the page it's on.

For personal and small sites, SEO Health Basics for Personal Websites and Portfolios turns this into a short routine.

Disclosure: I build Uchik, which covers the crawling side. Uchik checks your site daily and emails a report of broken links, missing images, redirect chains, mixed content and basic on-page SEO gaps, each tied to the exact page and HTML element. How it works explains the method, and the features page lists what it checks. It doesn't measure Core Web Vitals; use Search Console and PageSpeed Insights for that. The FAQ covers other limits, including that links added only by JavaScript may be missed. You can sign up for free.

Summary

A 404 on its own isn't a ranking penalty, but a 404 on a page that ranked removes it from the index.
Broken internal links hurt discovery, and homepage catch-all redirects are explicitly discouraged.
Core Web Vitals are used by ranking systems, but relevance comes first and good scores don't guarantee top rankings.
Redirect chains and images without dimensions are both link-health and performance problems.
The biggest cost of broken links is usually visitors, not rankings.

How to Audit Internal Links on a WordPress Site

Sandeep Singh — Sun, 18 Oct 2026 15:53:30 +0000

Internal links are the roads inside your website. They're how visitors move from a blog post to a product or service page, how they find related content, and how search engines discover and understand your pages. Google's own guidance says it plainly: "Every page you care about should have a link from at least one other page on your site" (Link best practices).

WordPress sites are especially prone to internal link problems because they grow over years. Posts get updated, slugs change, categories get reorganised, plugins come and go, themes get swapped, and the site gets moved between hosts or from staging to production. Each of those leaves some links pointing somewhere they shouldn't.

The result is lost traffic you never see: a reader following "read my full guide" hits a 404 and leaves, a high-converting landing page has no links pointing to it so nobody finds it, and search engines spend their time on redirects instead of your content.

This guide walks through a full internal link audit using free tools, then shows how to fix problems at the source rather than piling up redirects.

What you're looking for

An internal link audit checks for six things:

Broken internal links: links to pages on your own site that return 404 or another error.
Redirected internal links: links that work but go through one or more redirects first.
Orphan pages: published pages that no other page links to.
Deeply buried pages: important pages that take many clicks to reach from the homepage.
Weak anchor text: "click here" and "read more" instead of descriptive text.
Leftover URLs: links to your staging domain, http:// versions or old domain.

Step 1: Crawl the site

You need a full list of every internal link: the page it's on, where it points and what status that target returns. Some free options:

Screaming Frog SEO Spider (free up to 500 URLs; limits). Enter your homepage and crawl. Use Response Codes to filter internal URLs by status, and the Inlinks tab at the bottom to see every page that links to a selected URL, with anchor text.
The Broken Link Checker plugin (WordPress.org) checks links from inside WordPress and lets you edit or unlink from its dashboard. Plugin-based checkers use your server's resources, so check its settings on shared hosting.
Google Search Console's Links report shows your most internally linked pages from Google's point of view. It won't show broken links directly, but it's a useful sanity check.

A crawler that starts from your homepage only finds pages reachable by links. That's exactly what you want for steps 2–5, and it's why orphan pages need a separate check in Step 4.

Step 2: Fix broken internal links

Filter the crawl for internal URLs returning 4xx and 5xx. For each one, open Inlinks to see which posts or pages contain the bad link.

Common causes on WordPress:

A post slug was changed. WordPress core tries to rescue some of these: its wp_old_slug_redirect() function attempts to find a post's current slug from past slugs and redirect (WordPress developer reference). That doesn't cover every case, such as pages, custom post types on some setups, or posts that were deleted and recreated.
The permalink structure was changed in Settings → Permalinks (WordPress docs). Links hard-coded in old content keep the old format.
A page was deleted or unpublished.
A plugin that created pages was removed: shop, events, forums, landing page builders.
Category or tag base changed, breaking every category link in old posts.
Typos in manually entered links.

Fix the link in the content where it appears: edit the post, menu or widget and point it at the correct current URL. If the destination genuinely no longer exists, either link to the best replacement or remove the link.

Step 3: Update redirected internal links

Next, filter for internal links returning 3xx. These work, but every redirect is an extra request before the page loads. Lighthouse notes each redirect can delay a page "by hundreds of milliseconds" (Avoid multiple page redirects), and chains make it worse.

Typical WordPress sources:

Links to http:// versions of your own pages, redirected to https://
Links to www when the site lives on the bare domain (or the reverse)
Links missing the trailing slash, redirected to add it
Old slugs being rescued by a redirect plugin

Redirects are the right tool for external links and old bookmarks. For your own internal links, update the link to the final URL so visitors and crawlers get there directly. If you're seeing chains or loops, I covered fixing those in Redirect Chains and Loops: What They Cost an Ecommerce Site and How to Fix Them, and Mixed Content and Missing Images: A Practical Fix Guide for Store Owners covers the related http:// asset problem.

Bulk-fixing domain and protocol changes

If thousands of links point at an old domain or http://, editing posts by hand isn't realistic. WP-CLI's search-replace handles it, including serialized data in options and widgets:

# Always preview first, and take a database backup
wp search-replace 'http://example.com' 'https://example.com' --dry-run
wp search-replace 'https://staging.example.com' 'https://example.com' --dry-run

Remove --dry-run only after checking the counts look right. Many hosts and migration plugins offer a similar search-and-replace tool if you don't have shell access.

Step 4: Find orphan pages

An orphan page is published but not linked from anywhere on the site. A link-following crawler can't find it, and visitors are unlikely to either.

To find them, compare what you've published with what the crawler found:

Get the list of published URLs from your XML sitemap. Since WordPress 5.5, core generates a sitemap index at /wp-sitemap.xml (Make WordPress Core); SEO plugins often replace it with their own, usually at /sitemap_index.xml.
Export the list of HTML URLs your crawler found by following links.
Anything in the sitemap but not in the crawl is an orphan.

A spreadsheet works for this: paste both lists into separate columns and use a lookup to flag sitemap URLs missing from the crawl.

For each orphan, decide:

Still valuable? Link to it from relevant posts, a category page or a hub page.
Outdated or thin? Update it, merge it into a stronger page (and redirect), or unpublish it.
Intentionally hidden (a thank-you page or a campaign landing page)? Consider whether it should be in the sitemap at all, or whether it should carry noindex.

Step 5: Check click depth for important pages

Most crawlers report crawl depth: how many clicks from the homepage each page is. Your most important pages (key services, best guides, top products) shouldn't be buried at depth 5 behind pagination.

Ways to bring them closer:

Link to them from the main menu or a footer section
Create a hub or "start here" page linking to your best content
Add contextual links from related, popular posts
Use breadcrumbs (many themes and SEO plugins provide them)

Step 6: Improve anchor text

Google says good anchor text "is descriptive, reasonably concise, and relevant to the page that it's on and to the page it links to", and that it helps "both people and Google make sense of your site" (Link best practices).

In the crawl's Inlinks or All anchor text export, look for:

Generic text: "click here", "read more", "this post", "here"
Empty anchors, such as image links with no alt text
The same exact keyword phrase used for every link to a page, which reads awkwardly

Rewrite them as natural descriptions: "see our guide to [choosing a running shoe]" rather than "[click here] for our guide".

Step 7: Check your theme and page builder output

Two WordPress-specific issues to verify:

Links must be real <a href> elements. Google says it can generally only crawl links that are <a> elements with an href attribute (Link best practices). Some page builders and theme widgets render buttons or "clickable boxes" with JavaScript onclick handlers instead. View the source of a few pages and check that menus, buttons and cards are real links.
Related-posts and widget links. These are generated automatically and can point at drafts, trashed posts or attachment pages. Check them in the crawl, too.

Step 8: Make it a habit

A one-off audit fixes today's problems. WordPress sites keep changing, so links keep breaking. A sustainable routine:

After every significant change (theme switch, permalink change, plugin removal, migration): crawl and fix.
Monthly: a quick crawl filtered for 4xx and 3xx internal links.
Quarterly: the orphan-page and anchor-text review.

The Website Maintenance Checklist for Small Business Websites puts internal link checks in context alongside backups, updates and renewals.

Disclosure: I build Uchik, which automates the recurring part. Uchik crawls your site every day and emails a report of broken internal and external links, missing images, redirect chains and HTTPS problems, each with the source page and the exact HTML element to fix. It runs as an external crawler, so there's no plugin to install or keep updated. The features page lists every check, the sample report shows the output, and the FAQ explains its limits, including that links added only by JavaScript may be missed. It doesn't do the orphan-page comparison in Step 4; keep that in your quarterly review. You can sign up for free.

Checklist

[ ] Full crawl from the homepage
[ ] Broken internal links fixed at the source
[ ] Redirected internal links updated to final URLs
[ ] Old domain, staging and http:// links bulk-replaced (with backup and dry run)
[ ] Sitemap vs crawl compared; orphans linked, merged or removed
[ ] Important pages within a few clicks of the homepage
[ ] Generic anchor text rewritten
[ ] Menus, buttons and cards confirmed as real <a href> links
[ ] Recurring check scheduled or automated

Internal links are the one part of your site's linking you fully control. A few hours of auditing keeps readers and crawlers moving to the pages that matter.

DEV Community: Sandeep Singh

Free Tools to Check Redirects, Broken Links, Mixed Content and Meta Tags (and When to Automate It)

1. Redirect problems

What it is

How it hurts rankings and sales

How to check it manually

The free tool

2. Broken links

What it is

How it hurts rankings and sales

How to check it manually

The free tool

3. Mixed content

What it is

How it hurts rankings and sales

How to check it manually

The free tool

4. Missing or bad SEO meta tags

What it is

How it hurts rankings and sales

How to check it manually

The free tool

A quick manual routine

When to automate it

Summary

A Technical SEO Checklist for Launching a New Website

Before launch

1. Decide your canonical hostname

2. HTTPS everywhere

3. Real 404s

4. Titles and meta descriptions

5. Crawlable links and navigation

6. Core Web Vitals baseline

7. If you're replacing an old site: map redirects

Launch day

8. Remove the staging noindex

9. Fix robots.txt

10. Sitemap

11. Search Console

12. Analytics

The first month

13. Watch Page indexing

14. Crawl your own site

15. Re-test after every deploy

Ongoing monitoring

The checklist

Image SEO for Blogs: Finding Missing, Broken and Unindexable Images

Why blog images break

Step 1: Find every broken image on the blog

Crawl the site and check image URLs

A quick script for a single post

Check for mixed content images

Step 2: Fix them

Step 3: Make images indexable

Use real <img> elements

Always include a src fallback

Use supported formats

Consider an image sitemap

Step 4: Alt text, filenames and context

Step 5: Images and Core Web Vitals

CLS: always set dimensions

LCP: don't lazy-load the hero

Step 6: Social preview images

Keep it from coming back

Checklist

Newsletter Link Rot on Substack, Ghost and beehiiv: Archive Checks That Work

Part 1: The pre-send check (two minutes per issue)

Part 2: Find every archive URL with the sitemap

Part 3: Audit the archive

Check every outbound link

Prioritise

Fix

Part 4: Your own URLs, the links you can actually control

Adding a custom domain

Changing platforms

Links between your own issues

Links in email bodies

Part 5: The quiet failure mode, reference rot

Part 6: A routine for busy writers

Automating the archive check

8. Remove the staging `noindex`

9. Fix `robots.txt`

Use real `<img>` elements

Always include a `src` fallback

The minimum viable `<head>`

1. `<title>`: the most important tag here