DEV Community: SEOSage

Hreflang: The Audit That Stops Your Pages Fighting Across Countries

Kessy Stalford — Tue, 13 Oct 2026 02:53:40 +0000

I work at SEOSage, which builds desktop SEO audit software. The steps below work with any crawler.

The wrong version of your page is ranking somewhere right now.

Hreflang tells Google which language or regional version of a page to show to which audience. When it is wrong — or missing — the US page ranks in the UK, the English page outranks the German one in Berlin, and your own pages cannibalise each other across markets. Nobody notices until a regional manager asks why their page never shows up locally. This audit finds every hreflang error before that conversation.

How hreflang breaks

Missing return links — page A declares itself the alternate of page B, but page B does not declare A back. Google ignores hreflang without reciprocity. This is the single most common error.
Wrong language or region codes — en-UK instead of en-GB, made-up codes, or language-only tags where region-specific ones were needed. One wrong code and the whole cluster is suspect.
No x-default — without a fallback page for unmatched audiences, Google guesses. Declare one.
Hreflang on non-indexable pages — tags pointing at noindexed URLs, canonicals pointing elsewhere, or pages that 404. Hreflang only works between live, indexable, self-canonical pages.
Conflicting signals — hreflang says these pages are alternates while the canonical says they are all the same page. Google trusts the canonical and your hreflang is decoration.

The audit: crawl the tags, then verify the cluster

Extract every hreflang tag. Crawl the site and export all hreflang annotations: page URL, declared language/region, target URL. Sitemap-declared hreflang counts too — gather both, because mismatches between header tags and sitemap declarations are their own failure mode.
Check reciprocity. For every A→B declaration, confirm B→A exists. Build the cluster map: every page in a language cluster should reference every other page in that cluster. A spreadsheet pivot does this in minutes.
Validate the codes. Check every language and region code against the standard lists. Flag anything Google does not recognise, and flag language-only tags where the business actually serves distinct regions.
Verify the targets are real. Every hreflang target must return 200, be indexable, and carry a self-referencing canonical. A hreflang pointing at a redirect or a noindexed page is a dead signal.
Cross-check Search Console. The International Targeting report (and the language report in newer GSC) shows which errors Google sees. Use it to confirm your crawl findings, not as the starting point.

Fix by cluster, not by tag

Hreflang errors cluster by template: one wrong include file breaks every product page in a market. Fix the template or the sitemap generator, not individual tags. The usual order: fix the codes first (cheap, global), then reciprocity (template-level), then target validity (page-level), then add the missing x-default.

Prioritise by traffic

Same habit as every audit: the broken cluster on the market that brings revenue outranks the one on a dormant locale. I overlay GA traffic on the crawl in SEOSage so the hreflang work lands where the visitors are — the same traffic-first habit, applied internationally. Any workflow that combines hreflang extraction with traffic gives you the same ordering.

The maintenance rule

Hreflang rots when sites change: new locales launch without tags, pages get noindexed without updating the cluster, templates get replaced and the include disappears. Re-run the hreflang extraction after every site change involving locales, templates, or canonicals — and audit the full cluster map quarterly. International SEO is the last place you want silent failures.

Disclosure: I work at SEOSage, a desktop SEO audit tool. These steps work with any crawler you already use. Do your language versions all link back to each other?

Broken Links: The Audit That Protects Every Page You Have

Kessy Stalford — Tue, 13 Oct 2026 02:28:11 +0000

Disclosure: I work at SEOSage, a desktop SEO audit tool. These steps work with any crawler you already use. When did you last run a full status-code crawl of your site?

Duplicate Content: How to Find and Fix Pages Competing With Themselves

Kessy Stalford — Mon, 12 Oct 2026 18:37:40 +0000

I work at SEOSage, which builds desktop SEO audit software. The steps below work with any crawler.

Your pages should not compete with each other.

Duplicate content rarely triggers a penalty — that is a myth for most sites. The real damage is quieter: when three near-identical pages exist, search engines split the ranking signals between them, pick a canonical you did not intend, and none of the versions ranks as well as one consolidated page would. This audit finds the internal competition and ends it.

The three kinds of duplication

Exact duplicates — the same page served at multiple URLs: trailing-slash variants, www vs non-www, HTTP vs HTTPS, uppercase vs lowercase, print versions. Usually a configuration problem, not a content one.
Near-duplicates — pages that differ only slightly: sorted and filtered views, paginated series, location pages with the city name swapped, tag pages echoing category pages. The most common and the hardest to see without a crawl.
Thin duplicates — pages with almost nothing unique: auto-generated tag archives, empty category shells, boilerplate service pages cloned per suburb. These dilute the site even when each URL is technically unique.

The audit: compare, don't guess

Compare the metadata. Export every title, meta description, and H1 from a full crawl. Sort by title: identical titles across different URLs are your first suspect list. Duplicate meta descriptions are the second. This one export catches most exact and template-level duplicates in minutes.
Check the content. For the suspect URLs, compare actual page content — many crawlers flag near-duplicate content with a similarity threshold. Focus on the template: if every location page is 95% identical, the fix is one content rewrite strategy, not fifty edits.
Map the canonicals. For each duplicate cluster, check where the canonical tag points. The most common finding: canonicals pointing at themselves on pages that should defer to a master version, or canonicals on pages Google has chosen to ignore because the content barely matches.
Cross-check Search Console. The Page indexing report's "Duplicate, Google chose different canonical than user" and "Duplicate without user-selected canonical" entries confirm which clusters Google actually sees as duplicates — audit evidence, straight from the source.

Fix by cluster, not by URL

Each cluster gets one decision:

Consolidate — one page should exist where three near-duplicates do. Pick the winner, move any unique value into it, and redirect the rest to it.
Canonicalise — when the duplicate URLs must stay live (sorted views, print pages), point every variant's canonical at the clean master URL.
Differentiate — when the pages deserve to exist separately (real location pages), give each genuinely unique content: local specifics, distinct services, original copy. Swapped city names are not unique content.
Remove — thin auto-generated pages that serve no user get noindexed or deleted, with their internal links updated.

Prioritise by traffic

Consolidation touches rankings, so start where the stakes are: clusters containing pages that already bring visitors. I overlay GA traffic on the crawl in SEOSage so the duplicate clusters sort by traffic — the same traffic-first habit, applied to duplication. Merge the earning clusters first; the thin archives can wait their turn.

The maintenance rule

Duplication regenerates. New plugins create new parameter views, new templates clone the old boilerplate, new locations get another swapped-city page. Re-run the title/meta comparison after every site change — it is the fastest tripwire in the whole audit set, and it catches new clusters before they split your signals again.

Disclosure: I work at SEOSage, a desktop SEO audit tool. These steps work with any crawler you already use. How many URLs on your site share the same title tag right now?

Schema Markup: How to Audit It Before Google Ignores It

Kessy Stalford — Mon, 12 Oct 2026 18:28:39 +0000

I work at SEOSage, which builds desktop SEO audit software. The steps below work with any crawler.

Schema does not buy you rankings. It buys you eligibility.

Structured data is not a ranking factor. It is a ticket to rich results — the review stars, prices, FAQ panels, and breadcrumbs that make your listing bigger on the search page. Most sites I audit have one of two problems: no schema where it obviously fits, or schema that is broken, misleading, or applied to pages where it can never win anything. Both waste the effort that went into writing it.

The audit: inventory first

Crawl and inventory every schema type. Extract all JSON-LD (and microdata) across the site: which pages carry schema, which types, which properties. You will usually find three things: templates that never got schema, templates with schema nobody maintains, and copy-pasted blocks from a plugin that do not match the page.
Check type-to-page fit. Each page should carry the schema that matches what it is — Article for posts, Product for product pages, LocalBusiness for the location page, BreadcrumbList everywhere relevant. A Product schema on a blog post, or FAQ schema on a page Google no longer shows FAQ rich results for, is effort spent in the wrong place.
Validate every type. Run representative URLs through Google's Rich Results Test. Fix invalid properties, missing required fields, and warnings on pages that matter. Warnings on low-traffic pages can wait — errors on the pages that earn cannot.
Match schema to content. The markup must describe what the page actually shows. Ratings with no visible reviews, prices that do not match the checkout, dates that expired years ago — this is how schema stops being eligible for rich results and starts looking like spam.

The common failures

Stale schema: sale prices from two years ago, events that already happened, reviews from a retired product. Schema rots faster than content.
Plugin duplication: two plugins injecting conflicting blocks on the same page. One source of truth per page type.
Invisible markup: FAQ schema answering questions that do not appear on the page, aggregate ratings with no reviews shown. Google treats this as misleading.
Wrong bets: schema types for rich results that no longer exist or never applied to the niche. Check what rich results your vertical actually gets before writing markup for them.

Prioritise by traffic

Same habit as every audit: fix the pages that earn first. I overlay GA traffic on the crawl in SEOSage so the schema work lands on templates that already bring visitors — the product pages with stars missing, the articles with breadcrumbs absent. A perfect FAQ block on a page nobody visits is the last item on the list, not the first.

The maintenance rule

Schema needs a review whenever content changes: new prices, new products, new posts, retired offers. Add schema to the publishing checklist — before a page goes live, the markup should be written, validated, and matched to what the page shows. And re-run the inventory after every template or plugin change; that is when duplicate blocks and stale markup sneak back in.

Disclosure: I work at SEOSage, a desktop SEO audit tool. These steps work with any crawler you already use. Which page on your site most obviously deserves schema it does not have?

Your Lab Scores Lie: An Audit Guide to Core Web Vitals That Actually Matter

Kessy Stalford — Mon, 12 Oct 2026 18:21:44 +0000

I work at SEOSage, which builds desktop SEO audit software. The steps below work with any crawler.

Google ranks on field data. You are probably measuring lab data.

Core Web Vitals come from real users — the Chrome User Experience Report, 75th percentile, over 28 days. Most audits I see start and end with a Lighthouse run: lab data, one machine, one network, no real users. Lab scores are a diagnostic tool, not the grade. This audit reads the field data first and only touches the lab to diagnose what the field says is broken.

The three vitals, in plain terms

LCP (Largest Contentful Paint) — how fast the main content appears. Under 2.5s is good. This is the one most sites fail, and it is almost always media and blocking resources.
INP (Interaction to Next Paint) — how fast the page responds when a user clicks or taps. Under 200ms is good. Heavy JavaScript is the usual culprit.
CLS (Cumulative Layout Shift) — how much the page jumps around while loading. Under 0.1 is good. Unreserved image and ad slots, late-loading fonts.

You do not need to memorise the thresholds. You need to know which template each failure lives on.

The audit: field first

Pull the field data. Open PageSpeed Insights for your homepage, one key landing page, and one template page (product, article, category). Then open Search Console's Core Web Vitals report — it shows the same field data grouped by URL pattern, which tells you whether the problem is one page or a whole template.
Group by template. If every blog post fails CLS, you fix the template once, not fifty pages. Template-level grouping is where this audit saves its time.
Diagnose in the lab. Only now open Lighthouse — for the failing templates, to find the cause: unoptimized images, render-blocking scripts, font swaps, layout-shifting banners.
Fix the pattern. Compress and properly size images, defer non-critical JS, reserve space for media and ads, preload the main font. One fix per template, verified in the lab, then rolled out.

Prioritise by traffic

Not all failing templates matter equally. A slow blog archive nobody visits loses to a failing product template that brings revenue. I overlay GA traffic on my audits in SEOSage so the vitals work lands on the templates that earn first — the same traffic-first habit, applied to performance. Any workflow that combines URL-level vitals data with traffic gives you the same ordering.

The field-data lag

Field data moves slowly — 28 days of real users. After you ship a fix, the lab improves immediately and the field report takes weeks. That is normal; do not roll back a working fix because Search Console has not caught up yet. Re-check the field report monthly, and re-run the lab right after every template change — that is when regressions are born.

Disclosure: I work at SEOSage, a desktop SEO audit tool. These steps work with any crawler you already use. When did you last check your field data instead of your Lighthouse score?

Crawl Budget: The Audit That Gets More of Your Pages Crawled

Kessy Stalford — Mon, 12 Oct 2026 17:59:32 +0000

Disclosure: I work at SEOSage, a desktop SEO audit tool. These steps work with any crawler you already use. What share of your crawl would you guess is junk URLs?

Internal Linking: How to Make Every Page Count

Kessy Stalford — Mon, 12 Oct 2026 16:49:50 +0000

Disclosure: I work at SEOSage, a desktop SEO audit tool. These steps work with any crawler you already use. How many clicks deep is your most important page?

Stop Trusting Your Sitemap: How to Reconcile It With a Crawl

Kessy Stalford — Mon, 12 Oct 2026 16:36:38 +0000

I work at SEOSage, which builds desktop SEO audit software. The steps below work with any crawler.

Your sitemap says one thing. Your site says another.

A sitemap is a declaration: "these are my important pages." A crawl is the evidence: "this is what is actually reachable." Most sites I look at have never reconciled the two. When I finally do the comparison for them, the gaps are always the same three buckets — and each bucket is an action list.

Bucket 1: In the sitemap, never crawled

These URLs cannot be reached by following links from the homepage. Some are true orphans your navigation forgot. Some are pages behind crawl blocks — noindex rules, robots disallows, or login walls you did not intend.

For each one, make a deliberate call: if the page matters, link to it from relevant pages. If it was retired, remove it from the sitemap and either let it 404/410 or redirect it to the closest live equivalent. The worst choice is doing nothing — a URL you declare but nobody can reach teaches crawlers to distrust your sitemap.

Bucket 2: Crawled, not in the sitemap

Most of these are fine — ordinary pages your navigation reaches. But scan the list for what should never be indexed: staging leftovers, parameter duplicates, thin archive and tag pages, old campaign landing pages. Being crawled is the first step toward being indexed, so this bucket is where index bloat is born.

The fix is not to add everything to the sitemap. It is to clean the crawlable site: noindex or block what should not be indexed, and keep the sitemap to pages that genuinely deserve to rank.

Bucket 3: Indexed, in neither list

Google found these through external links — old URLs, moved pages, retired campaigns. You did not declare them and your crawl cannot reach them, but they are in the index anyway.

Do not just add them to the sitemap to make the lists match. That bakes the mess into your declaration. Decide deliberately: redirect to the closest live page or let them go. A sitemap should contain only URLs that return 200, are indexable, and are the canonical version.

The reconciliation habit

A sitemap should be generated from the same system that builds the site, not maintained by hand — and it should be reconciled against a crawl after every redesign, migration, or CMS change. That is when the three buckets fill up: new templates create crawlable pages that never make it into the sitemap, and retired pages linger in the sitemap long after they stopped being reachable.

I do the reconciliation in SEOSage — it can crawl a sitemap directly and flag sitemap URLs that redirect or error alongside crawl-only and orphan URLs, with GA traffic overlaid so I fix the buckets in traffic order. Any crawler that supports sitemap crawl and orphan detection gives you the same three lists; the point is the comparison, not the tool.

Once the lists agree, most of the "mystery" problems people chase — pages that never get indexed, sitemap warnings that never go away, crawl budget spent on junk — tend to disappear on their own.

Disclosure: I work at SEOSage, a desktop SEO audit tool. These steps work with any crawler you already use. When was the last time you compared your sitemap against an actual crawl?

Redirect Chains: The Slow Leak in Your Site's Link Equity

Kessy Stalford — Mon, 12 Oct 2026 10:05:35 +0000

I work at SEOSage, which builds desktop SEO audit software. The steps below work with any crawler.

The crawl report says "redirect chain" and you ignore it

If you have ever run a site crawl and scrolled past a long list of redirect chains thinking "they resolve, so they work," you are not alone. Redirects do work for users — the browser eventually lands somewhere. The problem is quieter: every extra hop costs you. It costs crawl budget, because the crawler has to fetch two, three, or four URLs to see one page. It costs link equity, because the signal from external links decays a little with each hop. And on big sites it costs something harder to see — your internal links, your sitemap, and your actual site disagree about where the real pages live.

A chain is any URL that redirects more than once: /blog/old-post → /blog/new-post → /2024/blog/new-post → final URL. One redirect is normal. Two is a smell. Three or more is a leak you should fix.

Where chains come from

They are rarely made on purpose. They accumulate:

HTTP to HTTPS plus www to non-www plus trailing-slash cleanup — stack three "harmless" rules and every old link starts with a 3-hop journey.
Site redesigns — old URLs were redirected to new ones, then the new ones got redirected again in the next redesign. Nobody goes back and shortens the old rules.
Internal links that were never updated — the site itself keeps linking to the old URLs, so Google keeps discovering them and crawling the full chain every time.

That third one is the most common cause on sites that "fixed" their redirects years ago. The redirect rules are fine; the links are stale.

How to find them

Crawl the site and pull the redirect report. For every chain, record three things:

The start URL — where the chain begins (this is what your site or someone else still links to).
The final URL — where the chain lands. This is the real page. Everything should point here.
The hop count — anything over one hop is worth reviewing.

Then sort by traffic. Fixing a 4-hop chain on a page that earns visits matters; a chain on a page nobody visits can wait. This is exactly why I overlay GA traffic on crawl data in SEOSage — the fix list gets sorted by pages that already bring business, and I can see at a glance which chains are worth the edit. Any crawler that exports a redirect report gives you the raw data; the traffic overlay just decides the order.

How to fix them, permanently

There are two fixes, and you need both:

1. Update the links. Change your internal links and your sitemap to point at the final URL. The chain becomes almost irrelevant for internal traffic because nothing starts it. This is the fix people skip — they fix the redirect rules and leave the stale links, so the chain keeps getting crawled.

2. Shorten the rule. Where a chain starts from an old URL you still control (a legacy path, an old domain), point the rule directly at the final URL. /blog/old-post should go straight to the final destination, not through two intermediate versions.

After both, re-crawl. A proper fix shows as: zero chains with more than one hop on URLs your site actually links to. I re-run the redirect report in SEOSage after the changes because it flags any chain longer than one hop and shows start → final, so I can confirm every chain collapsed to a single redirect. Any crawler with a redirect report works for the same confirmation — the point is to verify, not to trust the fix.

The one-hop rule

From now on, treat it as a house rule: internal links always point at the final URL, and no chain may exceed one hop. It is a five-minute habit when you add or move a page, and it stops the slow leak before it starts.

Disclosure: I work at SEOSage, a desktop SEO audit tool. These steps work with any crawler you already use. What tool do you use to check your redirect chains?

Orphan Pages: How to Find and Fix Pages Nothing Links To

Kessy Stalford — Sat, 10 Oct 2026 05:08:19 +0000

An orphan page is a page on your site that no other page on your site links to. Search engines can still find some of them through your sitemap or external links, but visitors browsing your site never will — and crawlers deprioritise pages that nothing points at.

The good news: finding orphans takes about fifteen minutes with any desktop crawler. Fixing them takes longer, but the fix is a decision, not a technical trick.

Disclosure: I work with SEOSage, a desktop SEO crawler. Everything in this guide works in any crawler that reports internal links, including free ones. Delete every tool name and the process still works.

What you need

A desktop crawler that reports inlinks (links from your own pages to each page). SEOSage is the one I use day to day — a desktop crawler for Mac and Windows with unlimited local crawls on a flat $19/month or $149/year licence, which matters here because an orphan check is only trustworthy on a complete crawl. Screaming Frog SEO Spider (free up to 500 URLs) or Sitebulb (trial) work too, as long as the crawl covers the whole section you're checking.
Your XML sitemap URL — usually /sitemap.xml.
A spreadsheet with columns: URL / Inlinks / Decision / Done?

Step 1: Crawl the site

Run a standard internal crawl of your homepage with default settings. When it finishes, you need one number per URL: how many internal pages link to it.

Most crawlers show this as an "Inlinks" column in the internal tab. Export the full list of crawled URLs with their inlink counts to your spreadsheet.

Watch out for one trap: if your crawl is incomplete (you stopped it early, or your site is bigger than a free tier's URL cap), pages outside the crawled section will look like orphans when they aren't. Either crawl the whole site or crawl section by section (/blog/, /products/, etc.) and note which sections each orphan result actually covers. SEOSage now guards against this in the tool itself: it only reports orphan pages after a full crawl, and on a crawl stopped early it holds the orphan list back and notes why, instead of presenting partial inlink data as orphans.

Step 2: Find the zero-inlink pages

Sort your export by inlinks, ascending. The rows with 0 inlinks are your orphan candidates.

Now cross-check against your sitemap:

Fetch your sitemap (your crawler can usually crawl a sitemap directly, or download it and open it in a text editor).
List every URL in the sitemap that does not appear in your crawl at all. These are true orphans — pages that exist, are declared in your sitemap, but are not reachable by following links from your homepage. They are often the most important finds: old landing pages, forgotten campaign pages, or content that got unlinked in a redesign.
Merge both lists (0-inlink crawled pages + sitemap-only pages) into one candidate list.

Before you act, filter out pages that are supposed to be unlinked:

Thank-you / confirmation pages after form submissions
Checkout and account pages
Staging, test, or admin URLs that leaked into the sitemap (fix the sitemap, not the links)
Deliberate landing pages fed only by ads or email, where you do not want organic visitors wandering in from elsewhere on the site — these are fine, but write "intentional" in your Decision column so future-you does not "fix" them again

Step 3: Decide — keep, link, redirect, or remove

Every remaining orphan gets exactly one decision:

Keep and link (the default). The page has real content someone might want. Add links to it from the most relevant pages: the parent category page, a related article, or a "resources" hub. Two or three contextual links from genuinely related pages beat one link dumped in a footer. Write anchor text that describes the page, not "click here."

Redirect. The page is outdated or duplicated, but its URL may have external links or bookmarks. Redirect it (301) to the closest matching live page. Check first that the target is a 200 page, not another redirect — do not create chains.

Remove. The page has no value, no traffic, and no external links. Delete it, let it return a proper 404 (or 410), and remove it from the sitemap. A clean 404 for a worthless page is not an SEO problem.

Keep unlinked (rare, deliberate). Only for the intentional cases above — and only if they are also excluded from the sitemap, or you accept that the sitemap is telling Google the page matters while your links say it does not. That mixed signal is why most accidental orphans underperform.

How to choose quickly: open each orphan and ask, "If a visitor landed here from Google, would this page help them?" Yes → link it. Was yes once → redirect it. Never → remove it.

Step 4: Fix the sitemap while you are here

Your sitemap should list only pages that return 200, are indexable, and are the canonical version of themselves. While you have the crawl open:

Remove sitemap URLs that redirect (list the final destination instead)
Remove sitemap URLs with a noindex tag or blocked by robots.txt — sending Google a URL and telling it not to index or crawl it is a contradiction
Add any important page you just rescued from orphan status, if your sitemap is manual

If your sitemap is auto-generated by your CMS, fix the source (the page status or settings), not the file.

Step 5: Re-crawl and verify

Wait until your link changes are live, then re-crawl the same scope as Step 1 and re-export the inlink counts.

Check three things:

Every page you decided to "link" now has at least 1 inlink — ideally 2–3.
Every redirect you created lands directly on a 200 page in one hop.
Your orphan count dropped to only the intentional ones.

Diff the two exports. If a "fixed" page still shows 0 inlinks, the link you added is probably on a page outside the crawl scope, behind JavaScript your crawl did not render, or pointing at a URL variant (trailing slash, www vs non-www) that is not the canonical one. Fix the link target to the exact canonical URL.

A realistic timetable

Under 500 pages: one sitting, start to finish.
500–5,000 pages: crawl and analysis in one sitting; link fixes spread over a few days because they are small content edits, not one bulk action.
Bigger than that: work section by section; directories (folders) usually share templates, so fixing one category page often rescues a whole group of orphans at once.

The mistake to avoid is treating this as a one-time cleanup. Every redesign, migration, or menu change creates new orphans. Add "re-run the orphan check" to whatever checklist you already use after site changes, and it stays a fifteen-minute job instead of becoming an archaeological dig.

Quick recap

Crawl the site; export URLs with inlink counts.
Zero-inlink pages + sitemap-only pages = your orphan candidates.
Exclude intentional unlinked pages (thank-you, checkout, ad-only landers).
Decide per page: link it, redirect it, remove it, or deliberately leave it.
Clean the sitemap: 200, indexable, canonical URLs only.
Re-crawl and diff to verify every fix actually landed.

Do this once and your internal linking stops having silent dead ends — which usually does more for the pages you already have than publishing new ones on top of a broken structure.

Stop Fixing SEO Issues in the Order Your Crawler Lists Them

Kessy Stalford — Wed, 07 Oct 2026 08:25:59 +0000

Disclosure: I work with SEOSage, one of the tools mentioned near the end of this post. Everything before that section is tool-agnostic, and the workflow below works with a free crawler, a spreadsheet, and Google Search Console. I've tried to write this so it's still useful if you delete every mention of SEOSage — because it should be.

Every SEO crawler hands you the same thing: a long, intimidating list of issues, sorted by how the tool happens to organise them. Missing titles. Duplicate H1s. Redirect chains. Images without alt text. Pages with thin content.

And almost everyone — myself included, for longer than I'd like to admit — starts at the top of that list and works down.

That's the problem. Your crawler's list order is an accident of how the software groups issues. It has nothing to do with money, traffic, or what a visitor experiences today. A broken page nobody has visited in six months sits in the same list, with the same visual weight, as the landing page that earns you leads every single day and currently returns a 404 to half the people tapping your ad.

This post is about reordering that list by the one thing that actually matters: whether anyone is trying to use the page.

The real cost of list-order fixing

When you fix issues in crawler order, three things tend to happen:

You burn hours on invisible pages. Old tag archives, forgotten campaign landers, staging leftovers that somehow got indexed. Technically broken, practically irrelevant.
The urgent stuff waits. The money page with the redirect loop, the pricing page dropping out of the index, the checkout-adjacent page with the rendering problem. They were on page three of your export.
Clients and stakeholders can't see the point. "We fixed 1,400 issues" is a vanity metric. "We fixed the 11 pages people actually land on" is a result.

Traffic-first prioritisation flips the sequence: crawl everything, find out which broken pages people are actually reaching (or trying to reach), fix those first, then sweep the rest in descending order of real-world impact.

Here's the full workflow.

Step 1: Crawl the whole site, not a sample

Start with a complete crawl. If your site is small, this is trivial. If it's large, crawl in sections — templates, folders, subdomains — but make sure the union of your sections covers everything, including the dusty corners. You can't prioritise what you never crawled.

Capture, at minimum, for every URL:

Status code (200, 301, 404, 500, etc.)
Indexability (indexable, noindex, blocked by robots, canonicalised elsewhere)
Title and H1 presence/duplication
Redirect chains and loops
Inlinks (how many internal links point to the page)

One honest limitation: a crawler only sees what it can reach. Orphan pages with zero inlinks won't show up unless you feed the crawler extra URL lists. Pull URLs from your XML sitemap, your CMS export, or last year's crawl and add them as a supplementary list. The pages nobody links to and nobody visits are exactly the ones you may later decide to delete — but decide that on purpose, not by accident.

Step 2: Get your traffic data into the same table

Now export two things:

Google Search Console → Pages report (clicks and impressions per landing page, last 90 days is a good window)
Google Analytics (GA4) → Landing page report (sessions/engagement per page), if you have it

Join them to your crawl data on the URL. In a spreadsheet that's a VLOOKUP/XLOOKUP on a normalised URL (strip trailing slashes and tracking parameters first, or your match rate will be miserable).

You now have, for every page: what's wrong with it and whether anyone cares.

If you have no analytics access — a prospect's site, a brand-new domain — Search Console alone is a perfectly good traffic proxy. No traffic data at all? Fall back to inlinks as a rough importance signal: heavily internally-linked pages tend to be the ones the business cares about. But treat that as a distant second choice.

Step 3: Sort by "broken × visited"

Create a simple priority view:

Priority	Condition	Why
P0 — fix today	Error (4xx/5xx) or not indexable, and has sessions/clicks in the last 90 days	Real people are hitting a dead end right now
P1 — this week	Redirect chain, wrong canonical, or duplicate title on a page with traffic	Visited pages leaking equity or confusing Google
P2 — batch it	Issues on pages with impressions but few/no clicks	Google shows them; users don't pick them. Fix after P1
P3 — backlog/delete	Issues on pages with zero traffic and zero impressions	Fix cheaply, noindex, or remove. Don't gold-plate these

This table is the entire method. Everything else is execution detail.

The first time you do this, the P0 list is usually shockingly short — five to fifteen URLs on most sites — and shockingly important. I have seen a single redirect-looping service page, quietly eating paid and organic landings for weeks, surface instantly the moment traffic was overlaid on the crawl. In list-order world, it was issue #1,204.

Step 4: Fix in priority order, then re-crawl

Work P0 down. For each fix, note what changed and when. Then re-crawl and diff: confirm the status code changed, the canonical points where you intended, the chain collapsed to a single hop.

Re-crawling is the step people skip, and it's the only one that proves anything. "We changed it in the CMS" is not verification. Your crawler showing a clean 200 on the previously-broken money page is.

Then move to P1. P3 pages get a deliberate decision — fix, noindex, redirect to something relevant, or delete — rather than another pass of cosmetic repairs.

Doing this with whatever tool you already have

You do not need new software for this workflow. Honestly, a spreadsheet and forty minutes will get most sites 80% of the value.

Approach	How the traffic overlay happens	Watch out for
Screaming Frog (free or paid)	Crawl, then connect the GA4/GSC APIs (Configuration → API Access) or export CSVs and join in Sheets/Excel	Free tier caps at 500 URLs; URL normalisation before joining
Sitebulb	Crawl with GA/GSC data sources enabled in project settings, then filter reports by traffic	Schedule crawls so the overlay doesn't go stale
SEOSage (disclosure: my employer)	GA connection pulls sessions onto each crawled page; sort/filter the page list by traffic so broken-but-visited rows float up	Desktop app: crawl runs on your machine, so big crawls need the laptop plugged in and awake
Pure spreadsheet	Crawl export + GSC Pages export + `XLOOKUP`	Slowest, but zero cost and you learn your data intimately

Pick the row you already own. The method is identical; only the join mechanics differ.

What this changes in practice

Your reports get shorter and better. Instead of "2,300 issues found," you report "9 visited pages were broken; all 9 fixed and verified; next batch is 40 redirect chains on pages with impressions." Stakeholders understand that sentence.

Your crawl budget conversations get easier. Pages with zero traffic, zero impressions, and zero inlinks are candidates for removal, which shrinks the site Google has to crawl and stops those URLs diluting your reports forever.

You stop being afraid of the list. A 10,000-issue crawl export is paralysing. A P0 list of 11 URLs is a Tuesday morning.

A quick start for this week

Run one full crawl of your main site. Save the export; don't touch anything yet.
Export 90 days of GSC landing page clicks/impressions.
Join them. Normalise URLs first.
Filter: status ≠ 200 (or non-indexable) and clicks > 0. That's your P0.
Fix those, re-crawl, confirm.

If the P0 list comes back empty: genuinely good news, and now you know it instead of guessing.

Disclosure restated: I work with SEOSage. This post describes a workflow, not a pitch — it runs fine in Screaming Frog, Sitebulb, or a spreadsheet. SEOSage's angle on it is that GA traffic sits next to each crawled page so the sort in Step 3 is built in rather than a manual join, and crawls run locally on your Mac or Windows machine without a page cap. If the manual join doesn't bother you, you lose nothing by ignoring that entirely.

Found a broken-but-visited page this way that surprised you? I'd genuinely like to hear what it was in the comments.

How to Run Your First Technical SEO Audit (Free Checklist, Any Crawler)

Kessy Stalford — Mon, 05 Oct 2026 05:12:55 +0000

How to Run Your First Technical SEO Audit (Free Checklist, Any Crawler)

Your site is live, traffic is flat, and someone told you to "run a technical audit." That usually means opening a crawler, staring at 40 tabs of issues, and fixing things in whatever order the tool lists them.

Don't do that. Run the audit in this order instead — it takes about an hour on a small site, and you only need a free crawler to do it.

Disclosure: I work with SEOSage, one of the desktop crawlers listed here. Everything below works in any crawler, including the free ones. Skip the comparison table entirely and the checklist still does the job.

What you need before you start

A desktop crawler. Screaming Frog SEO Spider (free up to 500 URLs), Sitebulb (free trial), or any equivalent that runs on your own machine. Desktop crawlers run locally, so there's no upload queue and no per-page metering while you learn.
Google Search Console access for the site (free, and you'll use it to cross-check the crawl).
A spreadsheet to log what you found and what you changed. A simple sheet with URL / Issue / Fixed? columns is enough.
An hour with no meetings. Audits get abandoned halfway more often than they get finished.

Step 1: Crawl the site

Open your crawler, paste in your homepage URL, and start with the default configuration. For a first audit you don't need JavaScript rendering, external link checking, or API integrations turned on. A plain crawl of internal HTML pages is the right scope.

While it runs, note three numbers at the end: total URLs found, how many returned a 200 status, and how many were redirects or errors. Those three numbers are your baseline. Every fix below moves one of them.

If your site is bigger than your free crawler's limit, crawl in sections: homepage plus one directory at a time (for example /blog/, then /products/). The checklist works the same on a partial crawl — you just repeat it per section.

Step 2: Check status codes

Filter your crawl to non-200 responses and work through them in this order:

5xx errors (server errors). These are the only truly urgent ones. A 500 means the page is down for everyone, including Google. Fix the server issue or restore the page before anything else on this list.

404s (not found). For each broken URL ask two questions: does anything internal link to it, and did it used to have content? If it had content and internal links, either restore the page or redirect it to the closest equivalent. If it never had content and nothing links to it, leave it — a clean 404 is fine.

Redirects (3xx). A single redirect is not a problem. Chains are. Sort by redirect chain length and flatten anything with two or more hops so every old URL lands directly on the final page. Look specifically for loops (A → B → A), which crawlers flag clearly and browsers handle badly.

Write every fix into your spreadsheet as you go. Do not trust yourself to remember which 404 you decided to leave alone.

Step 3: Check indexability

A page can return a perfect 200 and still be invisible to Google. In your crawl, check three signals:

noindex tags. Look for pages carrying a meta robots noindex or an X-Robots-Tag: noindex header. On a first audit, most of these are staging leftovers or a theme default someone forgot to remove. Every important page — homepage, services, products, key articles — should be indexable.
robots.txt blocks. Check whether any important directory is disallowed. Crawlers show this as "blocked by robots.txt." A blocked page can't be crawled, so Google only sees it if other sites link to it.
Canonical tags. Each page should either canonical to itself or deliberately point at a preferred version. Watch for: canonicals pointing to the homepage from every page (a classic plugin misconfiguration), canonicals pointing at redirected URLs, and missing canonicals on paginated or parameter versions of pages.

Cross-check in Search Console under Pages → Why pages aren’t indexed. If the crawler and Search Console disagree, believe Search Console about what Google actually did, and use the crawler to find the cause.

Step 4: Check titles and headings

Filter for these four problems:

Missing title tags. Usually templates that were never finished.
Duplicate titles. Often product or category pages generated from the same template. Rewrite the worst offenders manually; fix the template for the rest.
Missing or multiple H1s. One H1 per page that matches what the page is actually about. Multiple H1s aren't a disaster, but a missing H1 usually means a heading structure problem worth fixing.
Overly long titles. Anything much over ~60 characters gets truncated in results. Shorten the ones on pages you actually want clicked — don't churn through all of them.

Do not rewrite every title on the site in one sitting. Fix missing and duplicate first; they carry the most weight for the least effort.

Step 5: Check internal linking and orphan pages

Internal links are how both visitors and crawlers distribute attention around your site. Look for:

Orphan pages: URLs with zero internal links pointing to them. Crawlers compute this from the crawl itself; Search Console also lists some under "Alternate page" reports. If a page matters, link to it from a relevant parent page. If it doesn't matter, consider removing it rather than leaving it stranded.
Pages buried too deep: anything more than 3–4 clicks from the homepage tends to get crawled rarely and ranked weakly. Flatten where it makes sense for humans, not just bots.
Broken internal links: every internal link pointing at a 404 or a redirect chain is wasted. Your status-code work in Step 2 gives you the target list; now fix the source links.

Step 6: Compare sitemap vs crawl

Your XML sitemap is a promise; your crawl is the reality. Compare the two lists:

In sitemap but not crawlable (404, redirected, noindexed): remove or fix. A sitemap full of dead URLs wastes crawl attention and signals neglect.
Crawlable and important but not in sitemap: add it, especially new sections the sitemap generator missed.
Redirected URLs in the sitemap: update them to the final destination URL.

In Search Console, submit the cleaned sitemap and note the date. Sitemap fixes are boring and genuinely effective — this is the step people skip that shouldn't be skipped.

Step 7: Re-crawl and diff

A week after your fixes (or immediately, for status-code fixes), crawl again with the same configuration and compare:

Total non-200s down?
Redirect chains flattened?
noindex only where you intended it?
Sitemap and crawl now matching?

This before/after diff is your report. If you do audits for clients, this comparison — not the raw issue count — is what demonstrates the work. If it's your own site, the diff tells you whether to keep going down this checklist or move to content work.

Which crawler should you use?

Any desktop crawler that runs locally will do this whole checklist. The honest differences:

Tool	Platform	Free tier	Practical note
Screaming Frog SEO Spider	Mac, Windows, Linux	Free up to 500 URLs	The long-standing default; paid licence removes the cap
Sitebulb	Mac, Windows	Trial	Strong visual reports and prioritised hints
SEOSage	Mac, Windows	14-day trial	Desktop crawler with unlimited local crawls and traffic data overlaid on issues

Disclosure again, since one row is mine: I work with SEOSage. Pick based on your OS, site size, and whether the free cap covers you — the checklist above is identical in all three.

Your first-audit recap

Crawl with defaults; note your baseline numbers.
Fix 5xx, then 404s, then flatten redirect chains and loops.
Remove accidental noindex and robots blocks; sanity-check canonicals.
Fix missing/duplicate titles and broken heading structure.
Link or remove orphan pages; fix broken internal links.
Clean the sitemap so it matches reality.
Re-crawl and diff to prove it worked.

Run this once a quarter and after any site migration, redesign, or traffic drop you can't explain. The first pass takes an hour; later passes take twenty minutes because you're mostly reading the diff.

Have a step you always add to a first audit? I'd genuinely like to hear it in the comments.