1. Know the 2026 baseline

• Accept that rel="next/prev" is not used by Google for indexing (since 2019). Optional, harmless, not a lever.
• Focus instead on crawlable <a href> pagination links and correct canonicals.
• Remember: crawl waste on small sites is about clarity, not penalties.

2. Paginated lists (/page/2/+)

• Page 2+ has a self-referencing canonical, not one pointing to page 1.
• Pagination links are plain HTML links (infinite scroll also exposes /page/N/ URLs).
• Posts per page set to 12–20 to reduce depth.
• Oldest important posts are reachable within ~3–4 clicks via hubs or categories.
• If you noindex page 2+, every post is still linked from somewhere indexable and in the sitemap.

Refresher on canonical logic: How to fix duplicate content with canonical tags.

3. View All vs paginated

• Use a View All page only if it loads fast (good LCP/INP on mobile).
• If using View All as canonical, paginated pages canonical to it consistently.
• Otherwise keep paginated pages self-canonical.

4. Author archives

• Single author: noindex or disable /author/name/ (it duplicates /blog/).
• Multi author: keep indexable only with real bio, photo, expertise and profile links.
• No /author/admin/ slug exposed; rename the user nicename/display name.
• Author archives excluded from the sitemap if noindexed.

5. Date archives

• Noindex or disable year/month/day archives unless chronology is the content.
• Remove "Archives" date widgets from sidebar/footer.
• Exclude date archives from the XML sitemap.

6. Parameter page= URLs

• Search for ?page=, ?paged=, ?orderby= variants in GSC and crawl tools.
• Canonical them to clean /page/N/ or base URLs.
• Do not robots.txt-block URLs you want Google to read canonicals on.
• Share clean links externally; a free URL shortener helps for campaigns.

7. Infinite scroll / Load more

• Every JS-loaded chunk also exists at a real /page/N/ URL.
• A plain HTML link to the next page is present in source.
• Test with JavaScript disabled: older posts still reachable.
• URL updates (History API) as users scroll, so shared links land in the right place.

8. Titles on paginated pages

• Plugin appends "Page N of X" to titles of page 2+.
• No hand-written unique meta for each list page; a pattern is enough.
• Category pagination follows the same rules as blog pagination.

9. Plugin settings

• Yoast: Advanced > Author/Date archives set to not show in search results.
• Rank Math: Titles & Meta > Authors / Misc Pages set to noindex.
• SEOPress: Titles & Metas > Archives > noindex author/date.
• Sitemap index rechecked after the change.

10. Verify in Search Console

• Pages report: check "Duplicate without user-selected canonical" for archive URLs.
• URL Inspection on /page/2/ and an author URL: confirm Google-selected canonical.
• Re-check after 2–4 weeks.

Common mistakes to avoid

• Canonical everything to the homepage. Some themes or old plugins set a site-wide canonical. Every archive then claims to be the homepage, and Google ignores the hint. Check source on three different URL types.
• Noindex plus robots.txt block. If you block a URL in robots.txt, Google can't see the noindex tag, so the URL may stay indexed as a bare link. Pick noindex and let it be crawled.
• Disabling archives without redirects. If author archives were indexed and linked externally, a 301 to the About page preserves value; a sudden 404 wastes it.
• Forgetting the sitemap. A noindexed URL listed in the sitemap sends mixed signals. Regenerate after changes.
• Fixing it once. New themes and plugins reintroduce archive widgets and parameter links. Re-run this checklist after any theme switch.

Why this still matters in 2026

Google is good at ignoring junk URLs on its own. But on a small site, every crawl of /2022/07/ or /author/admin/page/4/ is a crawl that didn't refresh a post you just updated. Tidy archives also make Search Console reports readable, so real problems stand out.

Quick decision table

More WordPress technical SEO notes on the blog; free utilities on the tools page.

Why bother in 2026? Google still uses BreadcrumbList to understand site structure and to show the path in results. Thin tag and category archives are still one of the biggest sources of wasted crawl on small blogs. Neither is glamorous, and fixing both usually takes one sitting.

Minutes 0–5: count your breadcrumb sources

Open three URLs: a post, a page, and a category archive. On each one:

• View the source and search for BreadcrumbList.
• Run the URL through the Rich Results Test.

Pass: exactly one BreadcrumbList per URL. Fail: two or more (theme microdata plus Rank Math/Yoast JSON-LD plus WooCommerce, for example). Keep the SEO plugin's version and turn off the theme's breadcrumbs in the Customizer or theme options.

Minutes 5–12: match the visible trail to the markup

For the same three URLs, write down the crumbs you can see and compare them with the itemListElement list in the markup.

• Same number of positions
• Same labels (no slugs like "blog-2" in the schema)
• Same category in the middle crumb

If the middle crumb differs, it's almost always because no primary category is set. Set one on your top 10 posts now and note the rest as a follow-up. If you still have an "Uncategorized" category, rename it to something real.

Minutes 12–17: check every crumb URL

Click every link in the trail.

• Each one returns 200 (no redirect hop)
• Each one uses your canonical host and protocol
• None of them is noindexed

A crumb pointing to a noindexed or redirecting archive is a mixed signal. Fix the link, or make that level a real hub. If you're not sure which version of a URL is the "real" one, my guide to fixing duplicate content with canonical tags walks through it.

Minutes 17–27: triage tags and categories

In GSC, go to Performance → Pages and filter by /tag/, then by /category/. Then open Indexing → Pages → "Crawled – currently not indexed".

For each term, decide:

Plugin paths: Rank Math → Titles & Meta → Tags/Categories; Yoast → Settings → Taxonomies.

Minutes 27–32: other archive types

• Date archives off or noindexed
• Author archives noindexed on single-author sites
• Post-format archives off
• Media attachment pages redirect to the file or the parent post (both plugins have a toggle)

Minutes 32–36: pagination

Open /category/your-main-category/page/2/.

• Canonical points to itself, not to page 1
• Not noindexed if the category is indexable
• Normal links to page 3 and back to page 1

If a category goes past 8–10 pages, link to the older posts directly from a hub page or split the category into subtopics.

Minutes 36–40: sitemap and links

• Noindexed taxonomies don't appear in the sitemap index
• Merged categories have 301s and no internal links still point at the old URL
• Links you share in newsletters or socials use clean URLs. I use a free URL shortener so tracking parameters don't create more URL variants.

Request indexing for one fixed post and one category hub, then come back in two weeks to see whether the "Crawled – currently not indexed" count for taxonomy URLs has gone down.

Three mistakes to avoid while you're doing this

• Noindexing every category at once. Good categories are useful hubs. Only noindex the thin ones, and merge where you can.
• Using nofollow on archives. Use noindex, follow, so crawlers can still reach the posts listed on the archive.
• Deleting terms without redirects. If an archive URL has backlinks or impressions, 301 it to the closest category.

Save this checklist

1. One BreadcrumbList per URL
2. Visible trail = markup
3. Primary category set; no "Uncategorized"
4. Crumb URLs are 200, canonical, and indexable
5. Tags noindexed, follow kept
6. Thin categories merged with 301s
7. Date, author, and format archives handled
8. Pagination canonicalises to itself
9. Sitemap matches your index decisions

More short checklists are on my blog, and free utilities are on the tools page.

2026 reality check: Google does not show FAQ or HowTo rich results for ordinary sites anymore. Clean markup anyway (spammy/invisible FAQ still looks bad to validators and other consumers). Put real eligibility energy into accurate LocalBusiness.

Forty minutes is enough for Home, top services/locations, and one real FAQ URL. It is not enough to invent a Schema.org strategy deck — and you should not.

Before you start (4 minutes)

Write five lines: money URLs; whether Rank Math, Yoast, or both write schema (keep one); any dedicated FAQ page; Google Business Profile name/phone/address; known Rich Results / GSC structured-data warnings.

If the same FAQ copy lives on overlapping URLs, settle ownership with canonical tags before polishing JSON-LD on a duplicate.

Part 1 — Inventory schema types (8 minutes)

• View source or plugin schema preview on Home, 3 money URLs, 1 blog post, FAQ page (if any)
• Note every FAQPage, HowTo, LocalBusiness / Organization emission
• Flag two plugins both writing the same type
• Flag FAQ JSON-LD on pages with no visible Q&A
• Flag the same FAQ questions repeating across URLs
• Flag HowTo on marketing/pricing pages that are not procedures

Pass: a short list of URLs with one concrete schema problem each.
Fail: enabling more schema types while invisible FAQ still ships sitewide.

Part 2 — FAQ blocks without spam (8 minutes)

• FAQ markup only where users can read the questions and answers
• Remove Rank Math / Yoast / theme FAQ blocks used only to inject JSON-LD
• Kill sitewide/footer/reusable-block FAQ that duplicates the same FAQPage everywhere
• One FAQ section per topic URL — not Home + every service + every post
• Questions sound like real customer questions, not keyword stacks

Prefer: visible accordion or static Q&A on a dedicated FAQ or a single money page.
Avoid: hidden FAQ “for SEO” and global patterns that stamp identical FAQPage nodes.

Pass: FAQ schema appears only where FAQ content is primary or clearly visible.
Fail: “FAQ rich results” toggles still on after Google retired ordinary FAQ stars.

Part 3 — HowTo only for real procedures (6 minutes)

• HowTo only on instructional URLs (ordered steps a human can follow)
• Each step has real text (not empty HowToStep / slogan-only steps)
• Disable auto-HowTo on numbered marketing lists
• No sitewide HowTo “just in case”

Pass: HowTo graph matches a genuine tutorial.
Fail: “How we work” sales page wrapped as HowTo.

Part 4 — LocalBusiness NAP (8 minutes)

• Single LocalBusiness (or clear Organization + location) — not theme + SEO plugin + directory plugin racing
• name, address, telephone, url match footer and GBP
• url is the stable homepage / location URL — not a campaign short link (URL shortener is fine for ads; keep it out of LocalBusiness url)
• Update schema when the phone or address changes
• Drop conflicting second NAP blocks

Other utilities: tools.

Pass: one NAP story humans and markup both tell.
Fail: prettier sameAs list while the phone in JSON-LD is two years old.

Part 5 — Required properties + Rich Results Test (6 minutes)

• Fill basics you can prove; skip vanity properties you cannot support
• Run Rich Results Test on each money URL you changed
• Treat FAQ/HowTo detections as hygiene signals in 2026 — remove junk; do not expect FAQ stars
• Fix LocalBusiness / Organization errors until clean
• Re-test after plugin or theme updates

Pass: money URLs validate for the types you intentionally keep; spam types gone.
Fail: “we added more schema” while NAP still mismatches GBP.

Done criteria

You are done when invisible/duplicate FAQPage is gone, HowTo exists only on real procedures, LocalBusiness NAP matches footer + GBP, required basics are filled, and Rich Results Test is clean for the types you still use. Leave a full Schema.org redesign for later.

Closing

FAQ / HowTo / LocalBusiness hygiene fails from spammy FAQ blocks, duplicate FAQ everywhere, HowTo on non-howto pages, NAP mismatches, and missing required properties — not from missing an enterprise knowledge graph. Mark up what users see; keep LocalBusiness honest; stop paying plugin toggles for rich results Google already retired.

More practical notes: blog.

— Riichi Mirza

Forty minutes is enough to fix Home and the URLs that earn leads. It is not enough to rename every 2019 Media Library dump — and you should not start there.

Before you start (4 minutes)

Write five lines: money URLs (Home, top services/posts); SEO plugin in use (one only); whether a sitewide default OG image exists; known bad shares (theme screenshot, logo-only cards); hero strategy (page builder background vs <img>).

Settle which URL owns overlapping content with canonical tags before you polish OG on a duplicate.

Part 1 — Inventory media + OG (8 minutes)

• Sample: Home, 5 money URLs, 3 posts with featured images
• View source / plugin preview: og:title, og:description, og:image, og:url
• Flag theme screenshot or generic logo as og:image
• Flag OG title that still says Home/tagline on a deep URL
• Flag heroes without width/height (or reserved aspect-ratio)
• Flag heroes with loading="lazy" above the fold
• Confirm only one SEO plugin writes OG tags

Pass: list of URLs with a concrete media/OG problem each.
Fail: generating AI alts sitewide while /pricing/ still shares as screenshot.png.

Part 2 — Alt text without stuffing (7 minutes)

• Content images: one honest sentence of what the image shows
• Kill keyword stacks (plumber plumber services plumber…)
• Decorative icons/spacers: empty alt="" when they add no information
• Reused files: alt matches this page’s role, not a global dump
• Captions/nearby copy carry extra context — not the alt alone

Prefer: Technician replacing a water-heater anode rod in a utility closet
Avoid: primary keyword ×5 with no visual description.

Pass: alts a screen reader user would thank you for.
Fail: “SEO alts” nobody would say aloud.

Part 3 — Dimensions, weight, filenames (7 minutes)

• Heroes match layout width (often ≤1200–1600 CSS px) — no 4K dump in a half column
• File weight sensible (heroes often well under ~200–300 KB when quality allows)
• Modern format where easy (WebP/AVIF + fallback) — one optimizer, not five
• width + height set (or CSS aspect-ratio with reserved space)
• Future uploads named before Media Library (service-outcome-city.jpg, not DSC_01992.JPG)

Light LCP note only: oversized above-fold heroes are often the LCP element — shrinking them helps CWV as a side effect. This checklist still prioritizes discoverability and previews.

Pass: money heroes sized, weighted, dimensioned.
Fail: another compression plugin while the hero stays a 5 MB PNG.

Part 4 — Open Graph package (8 minutes)

• Sitewide default OG image set (brand-safe, ~1200×630)
• Money URLs override with relevant featured/social image
• og:title matches page intent (not leftover “Home”)
• og:description is page-specific where it matters — not only the tagline
• Absolute HTTPS image URLs after CDN/offload
• Re-scrape with Facebook/LinkedIn debuggers on URLs you changed

Campaign tracking can use a URL shortener; the landing page still needs correct og:*. Other utilities: tools.

Pass: fresh scrapes show the card you designed.
Fail: “we updated the plugin” while Slack still shows last month’s screenshot.

Part 5 — Lazy-load + builder gotchas (6 minutes)

• Above-fold hero: not lazy; consider fetchpriority="high"
• Below-fold galleries: lazy is fine
• Srcset so mobile is not handed the desktop master
• Page-builder “background images”: if they carry meaning, use <img> + alt or accessible text nearby
• One SEO plugin only; no duplicate og:image race in <head>

Pass: hero paints without waiting on a lazy placeholder.
Fail: sitewide lazy that includes the LCP image.

Done criteria

You are done when money URLs have honest alts, dimensioned/sensible heroes, real OG images (not theme screenshots), matching OG titles, and no above-fold lazy on the primary image. Leave historical Media Library renames for a later batch.

Closing

Image SEO and Open Graph fail from stuffed alts, missing dimensions, heavy heroes, mismatched OG, screenshot defaults, useless filenames, and lazy heroes — not from missing an enterprise DAM. Label media like you label titles: clear, honest, unique where it matters.

More practical notes: blog.

— Riichi Mirza

Forty minutes is enough to fix the URLs that earn leads. It is not enough to rewrite every tag archive from 2019 — and you should not. Prioritize money templates, then stop.

Before you start (4 minutes)

Write five lines: money URLs (Home, top services/posts, booking/contact if indexed); SEO plugin in use (one only); whether archives are indexed; known GSC HTML issues (duplicate/missing titles or descriptions); brand name length for truncation math.

Settle which URL owns overlapping content with canonical tags before you polish a duplicate’s title.

Part 1 — Inventory titles (8 minutes)

• Crawl or sample: Home, 5 money URLs, 3 blog posts, 2 category/tag archives, one paginated URL
• Flag duplicates (same <title> on different URLs)
• Flag stuffing (primary keyword repeated, city×3, "best best best")
• Flag truncation risk (unique benefit after a long brand/slogan prefix)
• Flag Untitled / Auto Draft / Just another WordPress site
• Confirm only one SEO plugin writes titles

Pass: list of URLs with a concrete title problem each.
Fail: rewriting random tags while /pricing/ still says "Home."

Part 2 — Rewrite money URL titles (10 minutes)

• One clear primary phrase near the front
• Brand at the end unless brand is the query
• Short separator (| or –); no triple stacks
• Specificity: city, outcome, format, or audience — one differentiator
• Preview ~50–60 characters / mobile cut; read the truncated string aloud
• Align H1 with the same document intent (not identical string required)

Prefer: Same-day leak repair in Austin | Acme Plumbing
Avoid: Plumber plumbing services plumber Austin plumber | Acme Plumbing Plumber Austin

Pass: each money URL unique, front-loaded, human.
Fail: longer title "for ranking" that truncates to nonsense.

Part 3 — Metas that earn the click (8 minutes)

• Custom meta on every money URL (blank = Google improvises, often badly)
• Problem → promise → qualifier in 1–2 sentences
• Planning range ~140–160 characters; accept rewrites
• Kill "Welcome to our website" and first-paragraph waffle autos
• If plugin uses excerpt, make excerpt intentional
• No stuffing; natural entity/benefit language

Pass: honest snippet candidates on conversion URLs.
Fail: identical meta pasted across ten pages.

Campaign tracking can use a URL shortener; the landing page still needs Search-facing title/meta that match the promise. Other utilities: tools.

Part 4 — Archives, templates, pagination (6 minutes)

• Category/tag/author titles distinct from cornerstone posts
• Homepage SEO title set explicitly (not only the tagline leftovers)
• CPT/product templates: spot-check one URL per type
• Pagination: page 2+ not identical to page 1 (or noindex per your policy)
• Remove sitewide useless prefixes themes inject before post titles

Pass: archives labeled as archives; posts labeled as posts.
Fail: every archive titled like the first article in the loop.

Part 5 — Click + match hygiene (4 minutes)

• No fake urgency on evergreen service pages
• No "free tool / secret" claims the page does not deliver
• Title and on-page H1 describe the same document
• After edits, spot-check live <title> and meta in View Source (cache!)
• Request indexing sparingly; snippets can lag

Pass: higher chance of qualified clicks.
Fail: CTR bait that bounces in ten seconds.

Quick decision table

Myths this checklist refuses

• Stuffing the keyword three times "for SEO"
• Longer titles always rank better
• One sitewide title string for every archive
• Leaving metas blank because "Google rewrites anyway"
• Clickbait that the page cannot keep
• Treating Open Graph titles as a substitute for Search <title> (fix Search first; reuse good copy for social later)
• Running Rank Math and Yoast (or any second title writer) "just in case"

What "done" looks like

1. Money URLs have unique, front-loaded titles
2. No stuffing; brand placement intentional
3. Blank metas filled on conversion URLs
4. Archives not clones of posts
5. Truncation checked on mobile-width preview
6. H1 and title intent aligned
7. One SEO plugin owns the output

That will not invent rankings overnight. It stops treating titles and metas as afterthoughts or keyword dumpsters.

Rerun after theme/SEO-plugin changes, site migrations, new CPT templates, or a new GSC duplicate-title spike.

More practical technical notes: blog.

Riichi Mirza — SEO freelancer focused on small WordPress and service sites.

Before you start (4 minutes)

Write five lines: money URL (not only Home); failing mobile metric (LCP/INP/CLS); host + CDN; theme/builder; front-end injectors already installed (cache/optimize/chat/slider/tags).

Measure that same URL before/after — settle which URL you tune the way you settle canonical tags when duplicates confuse crawlers.

Part 1 — Read the failure (6 minutes)

• GSC → Experience → Core Web Vitals (or CrUX): note mobile status for origin / URL group
• PSI or Lighthouse on the money URL (mobile); screenshot the LCP element
• Confirm LCP is image vs text/block
• Note TTFB vs "unused JS/CSS" noise; CLS culprits (images, fonts, banners); long tasks if INP or lab TBT is bad

Pass: known metric + element/template.
Fail: optimizing a random blog post while /pricing/ converts.

Part 2 — Plugin and pixel bloat (10 minutes)

• List plugins that print CSS/JS on the front end
• On staging, remove one unused class (chat or slider or unused builder widgets)
• One caching approach your host documents; kill duplicate minify/lazyload
• Defer non-essential tags off money templates if possible
• Re-run mobile PSI after the subtraction

Pass: fewer injectors; improvement without a new plugin.
Fail: a fifth "AI speed" plugin. Subtraction first — stacking often worsens INP.

Part 3 — Images and LCP (10 minutes)

• If LCP is an image: weight sane for mobile (resize before upload)
• WebP/AVIF where the stack supports them
• Width/height or aspect-ratio (CLS)
• LCP image not lazy-loaded; below-fold can be
• fetchpriority="high" on the true hero only
• No carousel competing with LCP on money pages

Pass: LCP image sized, prioritized, dimensioned.
Fail: 3MB hero lazy-loaded.

Campaign links can use a URL shortener; that is not image hygiene. Other utilities: tools.

Part 4 — Render-blocking + fonts (8 minutes)

• Count head CSS/JS on the money URL
• Delay/remove non-critical plugin assets on that template
• Do not blank-defer every stylesheet (layout/CLS risk)
• Fonts: fewer weights; font-display; skip icon fonts for three icons
• Sync third-party head scripts: move/delay/delete after testing menus/forms

Pass: first paint not waiting on unused builder CSS.
Fail: "eliminate all CSS" and a broken fold.

Part 5 — Host vs theme + CLS (7 minutes)

• Empty staging still slow TTFB? → host/plan/CDN
• TTFB fine until assets stripped? → theme/builder/plugins
• CLS: image dimensions; banners reserve space; embeds have height
• Re-check mobile lab; field CWV can lag days/weeks
• Document removals so the next plugin binge does not undo them

Pass: host vs theme called; obvious CLS shoves gone.
Fail: upgraded hosting while ten pixels still load.

Quick decision table

Lab tools help you triage. Field data (CrUX / GSC) is what Search-oriented CWV use. Do not ship a vanity desktop 95 and ignore mobile LCP on the URL that makes money.

Myths this checklist refuses

• Another optimizer plugin before subtraction
• WebP-as-magic when LCP is text/CSS/TTFB
• Deleting all CSS because Lighthouse said "render-blocking"
• Blaming only the host (or only the theme) without an empty-template test
• Treating desktop PSI as Core Web Vitals "done"

What "done" looks like

1. Known failing metric + money URL
2. One injector class removed
3. LCP element treated correctly
4. No duplicate lazyload/minify wars
5. Host vs theme called honestly
6. Obvious CLS fixed
7. No new optimizer until subtraction is measured

That will not invent rankings overnight. It stops treating CWV as a plugin-store category.

Rerun after theme/builder changes, new chat/tags, homepage redesign, host migration, or a new red GSC URL group.

More practical technical notes: blog.

Riichi Mirza — SEO freelancer focused on small WordPress and service sites.

Before you start (3 minutes)

Write five lines:

• Final host (HTTPS, www or apex — pick one)
• Certificate status (valid, covers that host)
• SEO / SSL plugin in use (Rank Math, Really Simple SSL, host panel, none)
• Top 5 money URLs that must look secure
• Whether staging still serves HTTP-only tools on the same brand host

Judge everything below against that list. Scheme/host confusion is the same class of problem as duplicate URLs — settle the intended HTTPS URL the way you settle canonical tags.

Part 1 — Scheme hop + WP addresses (7 minutes)

• http://YOUR-DOMAIN/ → one 301/302 to https:// on the intended host (no multi-hop theater)
• Apex vs www: one choice; HTTPS works on the chosen host
• WP Admin → Settings → General: WordPress Address and Site Address both https://
• No admin redirect loop when opening /wp-admin/ over HTTPS
• Certificate name matches the host users actually land on

Pass: single scheme hop; General settings HTTPS; admin reachable on HTTPS.
Fail: HTTP still serves content, or siteurl/home still HTTP.

Part 2 — HTTP leftovers in content and options (10 minutes)

• View-source Home: no same-host http:// in img, script, link, iframe
• View-source each money URL: same check
• Search content / widgets for hard-coded http://yourdomain
• Customizer CSS: no absolute HTTP asset URLs
• Plugin-stored full URLs (sliders, logos, OG) upgraded
• Dry-run DB replace http://yourdomain → https:// if needed (never blind-replace all http)

Pass: money HTML is HTTPS-clean for first-party assets.
Fail: hard-coded HTTP images or scripts on money pages.

Part 3 — Mixed content: active vs passive (8 minutes)

Open DevTools → Console + Security on Home and one money URL.

• Active mixed content (scripts, stylesheets, XHR, insecure iframes): zero blocked items
• Passive mixed content (images/video/audio over HTTP): none, or listed and scheduled to fix
• Third-party widgets/fonts/maps: HTTPS endpoints only
• Abandoned slider / analytics snippets on http:// removed or replaced
• Service worker / cache purged if it still maps old HTTP assets

Pass: no active mixed content; passive cleared or rare and documented.
Fail: menu/JS broken because a script was blocked as mixed active content.

Active breaks the page; passive mostly breaks trust. Fix active first.

Part 4 — Insecure forms + admin myths (7 minutes)

• Contact / newsletter / login / checkout forms: action is HTTPS (or empty/same-origin over HTTPS)
• AJAX to admin-ajax.php or REST over HTTPS
• Test submit once; Network tab shows no HTTP posts
• /wp-admin/ used over HTTPS (do not "fix" SSL by forcing admin back to HTTP)
• If admin looks broken: Console mixed content + siteurl + proxy X-Forwarded-Proto — not "HTTPS is unsafe for admin"

Pass: forms and admin stay on HTTPS without mixed active errors.
Fail: Chrome "Not secure" on a form page, or admin intentionally left on HTTP.

Part 5 — HSTS lightly + cleanup (5 minutes)

• HTTPS solid everywhere you need before HSTS
• Enable HSTS at host/CDN with a modest max-age first
• includeSubDomains only if every real subdomain is ready
• Skip preload until you are sure you will not need HTTP on that host
• Sitemap + internal links use HTTPS; GSC samples of leftover HTTP URLs noted
• External shares can use a URL shortener; on-site paths stay HTTPS. Other free utilities: tools

HSTS does not repair mixed content inside a page — it only trains browsers to skip HTTP next time.

Quick decision table

What "done" looks like

1. One clean http→https hop to the intended host
2. siteurl / home HTTPS
3. No active mixed content on money URLs
4. Forms post over HTTPS
5. Admin used over HTTPS
6. HSTS optional seatbelt after the above

That will not invent rankings. It stops Chrome and users from treating a "secured" WordPress site as half-migrated.

Repeat triggers

Rerun after: host/CDN changes, theme swaps, plugin installs that inject scripts, content imports, staging→prod URL replace, or any new "Not secure" screenshot from a client.

More practical technical notes: blog.

Riichi Mirza — SEO freelancer focused on small WordPress and service sites.

Before you start (3 minutes)

Write four lines:

• Production host (HTTPS, www or not)
• Whether a staging copy still exists
• SEO plugin in use (Rank Math / Yoast / other / none)
• Top 5 money URLs that must be indexable

Everything below is judged against that list.

Part 1 — Live robots.txt (8 minutes)

Open https://YOUR-DOMAIN/robots.txt in a private window (and curl if you can).

• File loads on production (not a parked/staging host)
• No Disallow: / or other whole-site block for User-agent: *
• /wp-admin/ disallow is fine; Allow: /wp-admin/admin-ajax.php is the usual companion
• No Disallow hitting /wp-content/, /wp-includes/, theme paths, *.css, or *.js unless you can defend it
• Sitemap: line points at the production HTTPS sitemap index
• No leftover staging hostnames in Sitemap lines
• Security / "optimization" plugins have not appended mystery Disallows

Pass: boring file; admin blocked; assets fetchable; sitemap URL correct.
Fail: sitewide or asset Disallows, or Sitemap pointing at staging.

Skip inventing huge Allow: lists if nothing relevant was disallowed. The CSS/JS myth is "Google can't render unless I Allow everything"; the real failure is an accidental Disallow on assets or /.

Part 2 — Sitewide discourage + headers (5 minutes)

• WP Admin → Settings → Reading → Discourage search engines is unchecked on production
• View-source on Home: no noindex in meta robots
• View-source on each of your 5 money URLs: indexable (or intentional exception documented)
• Response headers on Home: no sitewide X-Robots-Tag: noindex (check hosting/CDN/staging vhost leftovers)
• Coming-soon / maintenance plugins fully removed or confirmed not injecting robots tags

Pass: money URLs fetchable and indexable.
Fail: discourage still on, or headers/meta still noindexing the host.

Part 3 — Intentional noindex vs accidents (8 minutes)

In your SEO plugin (and theme if it hardcodes robots):

• List post types / archives set to noindex (search, authors, tags, thin categories, thank-you)
• Confirm each is intentional
• Flag any money page, pillar, or hub accidentally noindexed
• "Noindex" used as soft-delete → either unpublish/redirect or restore index + improve content
• When near-duplicate URLs remain, settle which one should be indexable with clear canonical tags — do not noindex and canonicalize in conflicting ways without a plan

Pass: only utility/thin URLs are noindex.
Fail: a revenue URL is noindex "from staging" or "temporarily."

Part 4 — noindex vs sitemap conflicts (6 minutes)

• Export or open sitemap children for posts/pages (or sample 20 URLs)
• Spot-check: any listed URL returns noindex in HTML/headers?
• Remove noindex URLs from the sitemap or remove noindex if they should rank
• Thank-you / cart / account: noindex + out of sitemap
• GSC Pages: sample Excluded by 'noindex' tag and Blocked by robots.txt — match to fixes above

Do not "fix" blocked URLs with mass Request indexing while Disallow/noindex still fire.

Part 5 — Staging leftovers (5 minutes)

• Staging subdomain: still passworded or Disallow — and not linked from production
• Production HTML has zero hrefs to staging hosts
• Old GSC staging property: sitemaps removed or property ignored
• External campaign links use production (a URL shortener is fine for shares; keep on-site paths clean). Other free utilities: tools

Quick decision table (keep beside the checklist)

If Google Search Console says Blocked by robots.txt, free the path (or accept URL-only listing). If it says Excluded by noindex, either remove the directive or stop asking for indexation via sitemap and links.

What "done" looks like

1. Boring production robots.txt
2. Discourage off; no sitewide X-Robots noindex
3. Money URLs indexable
4. noindex reserved for utility/thin URLs
5. Sitemap does not list noindex URLs
6. Staging cannot leak signals onto production

That will not invent demand. It stops your own stack from hiding the pages you claim matter.

Repeat triggers

Rerun after: migrations, host/CDN changes, security plugin installs, coming-soon toggles, SEO plugin resets, or when GSC fills with Blocked-by-robots / Excluded-by-noindex on URLs you care about.

More practical technical notes: blog.

Riichi Mirza — SEO freelancer focused on small WordPress and service sites.

This pass is not a sitemap hygiene rewrite (that is a separate triage). Focus: hubs, orphans, nav/footer bloat, and whether in-content anchors actually endorse the pages you care about.

Before you start (3 minutes)

Write four lines:

• Your top 5 money URLs (services, tools, or posts that should rank)
• Your intended hubs (category landings / pillar pages — even if imperfect)
• Preferred URL shape (HTTPS, www or not, trailing slash)
• Where links live today (Appearance → Menus, footer block, widgets)

Everything below is judged against that list.

Part 1 — Map hubs and money pages (8 minutes)

• List hubs that should organize clusters (aim for 2–5 on a small site)
• Open each hub: does it link to its spokes with context, or only show a bare post loop?
• Confirm each money URL appears in at least one of: primary nav, a hub, or recent in-content links
• Flag money URLs that only exist in the sitemap or footer

Pass: every money URL has a human-visible path from Home within 2–3 clicks.
Fail: a key page is only reachable via search or direct URL.

Add missing hub → spoke links before you touch plugins. When near-duplicates confuse which URL should receive the links, settle canonicals first — how to fix duplicate content with canonical tags.

Part 2 — Orphan spot-check (12 minutes)

You do not need a perfect crawl on day one.

• Export or open your post/page list (or sitemap children for posts + pages)
• Crawl with Screaming Frog free tier or manually check: Home, hubs, last 20 posts, primary menu destinations
• Pick 15 published URLs you thought mattered. Count inlinks from that crawl
• Mark 0 inlinks → orphan candidates (ignore thank-you, cart, account, pure legal)

Do not dump orphans into the footer as a batch fix.

Part 3 — Nav and footer bloat (7 minutes)

• Count top-level primary nav items. Target ~5–7 for a brochure/small content site
• Count footer links. If you are over ~15–20 mixed URLs, trim
• Remove city/service clones nobody updates
• Ensure footer does not merely mirror the entire sitemap
• Check reusable blocks / old theme footer patterns — menus alone may be clean while a block still bloats

Pass: a new visitor can name your three most important pages from the header alone.
Fail: every URL looks equally "important."

Part 4 — In-content anchors (7 minutes)

Open your last 5 published posts/pages:

• Each links to at least one older relevant URL (not only "next post")
• Each links up to its hub when a hub exists
• Anchors are readable phrases, not "click here" or stuffed exact matches
• Links use the final canonical URL (no http→https hop left in hrefs)
• No auto-linker firehose (first mention of every keyword sitewide)

Campaign/UTM variants stay out of on-site HTML. Keep share links tidy with something like a URL shortener for external campaigns; internal hrefs stay clean. Other free utilities: tools.

Part 5 — GSC sanity without busywork (3 minutes)

• Pages → sample 5–10 Discovered - currently not indexed URLs
• Ask: orphan? thin? wrong host/canonical? only in sitemap?
• Fix links or substance on the ones you still want — skip mass "Request indexing"

What "done" looks like

In one sitting you should have:

1. A short list of hubs and money URLs
2. Orphans either linked, merged, or consciously dropped
3. Leaner nav/footer
4. Recent content that points backward and upward
5. A tiny follow-up list (not a 200-row spreadsheet)

That will not invent demand for thin pages. It stops your own site from hiding the URLs you claim matter.

Repeat triggers

Rerun after: publishing sprees, theme/footer rebuilds, migrations, merging categories, or when Discovered-not-indexed piles up on URLs you thought were well linked.

More practical technical notes: blog.

Riichi Mirza — SEO freelancer focused on small WordPress and service sites.

This is the sitemap hygiene pass I run on freelance audits. It is not a soft-404 rewrite and not a full crawl-budget deep dive. Focus: what is in the XML list, whether lastmod is honest, whether orphans are hiding in plain sight, and how that lines up with GSC "Discovered - currently not indexed."

Before you start (2 minutes)

Write one line:

• Sitemap index URL you intend to submit (e.g. https://example.com/sitemap_index.xml or /wp-sitemap.xml)
• Preferred host format (HTTPS, www or not, trailing slash rule)

Everything below is judged against that.

Part 1 — Confirm the live file (5 minutes)

• Open the sitemap index in a browser / curl -sI. Expect 200, Content-Type XML (or text/xml).
• List child sitemaps (posts, pages, categories…). Note counts.
• In GSC → Sitemaps: only one primary index is submitted. Remove obsolete Yoast/Rank Math/core duplicates.
• Purge CDN/cache if the XML still shows deleted URLs after a cleanup.

Pass: one clean index, fetchable, matches the plugin you actually use.
Fail: 404 sitemap, or three competing submissions.

Part 2 — Spot-check URL quality (15 minutes)

Pick 15 URLs across posts, pages, and one taxonomy sitemap:

• Each returns 200 (not 301 into the list entry itself)
• URL is the canonical host/path you want indexed
• Raw HTML has no noindex if the URL is in the sitemap
• Canonical tag (if present) points to this URL, not a sibling

Fail patterns & fixes:

When duplicates keep confusing GSC, pair this pass with proper canonicals — how to fix duplicate content with canonical tags.

Part 3 — lastmod honesty (5 minutes)

• Open a post you did not edit this month. Does lastmod show today anyway?
• Edit one staging/test copy (or a low-risk draft you publish briefly) and confirm lastmod updates only then.
• Disable any "auto bump all dates on regenerate" behavior in the SEO plugin.

Pass: lastmod moves when content moves.
Fail: sitewide "updated today." Prefer older accurate dates over fake freshness.

Part 4 — Orphans vs endorsement (10 minutes)

Sitemaps discover. Internal links endorse.

• Export or copy sitemap URLs (or sample the largest child sitemap).
• Crawl or manually check: is each money URL linked from nav, a hub, or at least one relevant post?
• Mark in sitemap, not linked → add 1–2 contextual internal links or remove from sitemap until the page is worth endorsing.
• Mark linked money URL, missing from sitemap → include it (if indexable).

Do not put campaign parameter variants into the XML list. Keep share links clean (a URL shortener is fine for campaigns); sitemap stays on canonicals. Other free utilities: tools.

Part 5 — GSC triage without busywork (8 minutes)

• Sitemaps report: note discovered vs indexed — a gap is normal; a never-moving pile of thin URLs is a content problem.
• Pages → Discovered - currently not indexed: sample 10 URLs.
  • Should they be in the sitemap at all?
  • Are they orphans?
  • Near-duplicate of a stronger URL?
• Fix list + links + substance on the worst samples. Skip mass "Request indexing."
• Disable weak taxonomies (often tags/authors) from the sitemap if those archives are empty doorways.

What "done" looks like

In one sitting you should have:

1. A single submitted sitemap index
2. Only indexable 200 canonicals in the children
3. Honest lastmod
4. No obvious orphans among pages you care about
5. A short list of Discovered-not-indexed URLs with a next action (link, improve, merge, or delist)

That will not magic-index junk. It stops the sitemap from arguing against your own quality signals.

Quick reference

Keep this sticky note next to GSC: sitemap = discovery list, not an indexing switch. Clean URLs in, honest lastmod, real internal links, one submitted index. Everything else is editorial.

Repeat triggers

Rerun this checklist after: HTTPS/www cutovers, permalink changes, SEO plugin swaps, bulk imports, or when Discovered-not-indexed spikes without a content push.

For more practical technical notes, see the blog.

Riichi Mirza — SEO freelancer focused on small WordPress and service sites.

This is the one I use on freelance audits for sites under ~1,000 URLs. No paid tools required.

Before you start: write down the "final URL format"

Answer four questions in one line of notes:

• HTTPS? (yes — always)
• www or non-www?
• Trailing slash or not?
• Lowercase only?

Example: https://www.example.com/page-name/. Every check below compares against this.

Part 1 — Host-level checks (5 minutes)

Test the four entry variants of your homepage:

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

Pass: every variant reaches the final homepage in one 301 (or is already it). Fail: any variant shows two or more Location lines.

Common cause: separate HTTPS and www rules in different layers (host panel + .htaccess + plugin). Fix by consolidating into a single rule and disabling the duplicates.

• All four variants resolve in ≤1 hop
• All redirects are 301/308, not 302/307
• No meta-refresh or JavaScript redirects on the homepage

Part 2 — Crawl for chains and loops (10 minutes)

Crawl the site (Screaming Frog free tier, Sitebulb trial, or any crawler with a redirect report). Export:

• Redirect chains

• Redirect loops

• Internal links pointing to 3xx URLs

• Zero loops (fix these first — they break pages outright)

• Zero chains of 2+ hops

• Count of internal links to redirected URLs (goal: 0)

Part 3 — Redirect rule inventory (5 minutes)

List every place redirects can live:

• Each redirect is defined in one layer only
• No rule whose target is itself redirected (A→B where B→C)
• Old temporary (302) rules reviewed — permanent moves switched to 301

Part 4 — The homepage-dump check (5 minutes)

Filter your redirect list for rules whose target is /.

For each one, ask: was this URL genuinely the homepage? (/index.html, /home, old domain root — yes. A deleted blog post or product — no.)

Google commonly treats unrelated page → homepage redirects as soft 404s, so they don't preserve value and they clutter Search Console.

• Each non-homepage URL redirects to a relevant page or closest parent (e.g. /blog/)
• Truly retired content with no equivalent returns 404 or 410
• Search Console "Soft 404" list cross-checked against these rules

Part 5 — Signal consistency (5 minutes)

Redirects are one of three signals that should agree on the final URL:

• XML sitemap lists only final, 200-status URLs
• Canonical tags point to the final URL (not an http or non-slash variant)
• hreflang / Open Graph og:url (if used) match too

If canonicals are messy, fix them in the same pass — I cover the full process in How to fix duplicate content with canonical tags.

Bonus — Off-site redirects you control

• Short links point to final URLs (not old slugs)
• QR codes on print material resolve in one hop
• Social profile and directory links updated after URL changes

Short links and QR codes are the sneakiest chains because they live on paper or in old posts. Use a shortener where destinations are editable — e.g. a simple URL shortener — so a URL change is a 10-second fix instead of a reprint.

Fix order (when the audit finds problems)

1. Loops — broken pages, fix immediately.
2. Host-level chains — affect every URL on the site.
3. Homepage dumps — remap or 404/410.
4. Rule-to-rule chains — flatten so each source points to the final URL.
5. Internal links — update menus, footers, in-content links to final URLs.
6. Sitemap/canonicals — align with final URLs.
7. Re-crawl — confirm zeros.

How often to run it

• After any redesign, migration, HTTPS/host change or plugin swap
• After bulk deleting or merging content
• Otherwise, quarterly

Why bother on a small site?

Because unlike most SEO work, this one has a finish line. You can get to zero chains, zero loops and zero internal links to redirects — and stay there with a 30-minute check every quarter. Faster pages, cleaner Search Console, fewer mystery soft 404s.

More small-site technical SEO checklists on the Riichi Mirza blog.

This is the checklist I actually run. It's built for small sites (under a few hundred URLs) where you can check things by hand, without an enterprise crawler. Every check comes with what "pass" looks like and the fix if it fails.

Part 1: Is the tag there and well-formed?

☐ 1. Exactly one canonical in the raw HTML <head>. View source (Ctrl+U), not DevTools — you want what the server sends. Fail: zero, or two from a theme and a plugin. Fix: turn off one source. Usually keep the SEO plugin's and remove the theme's.

☐ 2. Absolute URL with the correct protocol and host. https://example.com/page/, not /page/ or http://. Fix: set the site URL correctly in your CMS / framework config.

☐ 3. No staging or dev hostnames. grep -r "staging\." ./dist or search the live source. Fix: make canonical base URL an environment variable and check it on deploy.

☐ 4. Not injected only by JavaScript. If the canonical only appears after render, Google may process it late or not at all. Fix: render it server-side or at build time.

☐ 5. Not contradicted by an HTTP header. curl -sI https://example.com/page/ | grep -i link Fail: a Link: <...>; rel="canonical" header that points somewhere different from the HTML tag.

Part 2: Does the target make sense?

☐ 6. Indexable pages self-canonicalise. Spot-check 10 pages across types: home, blog post, category, tool page, contact. Fail: inner pages pointing to the homepage. This is the single most damaging canonical bug I find.

☐ 7. The target returns 200. curl -sI <canonical-url> | head -1 Fail: 301, 404, or 5xx. Fix: point the canonical at the final destination URL.

☐ 8. The target is not noindexed. Canonical says "index that one"; noindex on that one says "don't." Google will pick its own answer.

☐ 9. The target self-canonicalises (no chains). A → B → C chains get ignored. Every canonical should land on a URL that canonicalises to itself.

☐ 10. Paginated pages self-canonicalise. /blog/page/2/ should canonicalise to /blog/page/2/, not /blog/.

Part 3: Do your other signals agree?

Canonicals are a hint. Google checks whether the rest of your site backs them up.

☐ 11. Host/protocol/slash variants redirect.

for u in http://example.com/ http://www.example.com/ https://www.example.com/ https://example.com; do
  echo "$u -> $(curl -s -o /dev/null -w '%{http_code} %{redirect_url}' $u)"
done

Pass: everything 301s to one version. If variants return 200, you need redirects, not more canonicals.

☐ 12. Sitemap lists only canonical URLs. No parameter URLs, no redirected URLs, no noindexed URLs.

☐ 13. Internal links use canonical URLs. Nav, footer, and in-content links should match canonical format exactly — same slash, same host, no tracking params. Tracking parameters belong on external campaign links (for example, links you shorten or turn into QR codes for print), not inside your own navigation.

☐ 14. hreflang (if used) points to canonical URLs. Small multilingual sites often reference non-canonical variants in hreflang, which cancels both.

Part 4: What does Google actually think?

☐ 15. Compare declared vs selected canonical in Search Console.

• Pages report: open "Duplicate, Google chose different canonical than user" and "Alternate page with proper canonical tag."
• URL Inspection: for your top 10 pages, note "User-declared canonical" vs "Google-selected canonical."

How to read it:

A simple log template

I keep a tiny sheet per audit:

Ten rows is usually enough on a small site to see the pattern. One root cause (a theme setting, a deploy variable, a missing redirect) tends to explain most rows.

After fixing

1. Request indexing for the 3–5 most important affected pages in URL Inspection.
2. Re-submit the sitemap.
3. Recheck the Pages report in 2–4 weeks. Canonical changes are processed on recrawl, so don't expect it to update overnight.

Summary

A healthy canonical setup on a small site is boring: one absolute self-canonical per indexable page, parameter variants pointing to clean URLs, redirects handling host and protocol, and a sitemap and internal links that agree. Run these 15 checks once, fix the root cause, and you'll rarely think about canonicals again.

I share more checklists like this from freelance audits on my blog, and keep a few free SEO-adjacent tools on the site as well.

— Riichi Mirza

Rather than debating theory, I use a three-bucket triage: Ignore, Watch, or Fix now. Here's how to sort your site in about 20 minutes.

The one ratio that decides everything

Before any tooling, estimate this:

Discoverable URLs ÷ URLs you want indexed

• Close to 1:1 → crawl budget is irrelevant to you.
• Around 3:1 to 10:1 → you have leaks worth watching.
• Above 10:1 → Googlebot is spending its time on junk, and new or updated pages will be slow to get picked up.

You can approximate "discoverable" by crawling your site with any desktop crawler (with JavaScript rendering on) and comparing its total to the URL count in your sitemap.

The triage table

If every row lands in Ignore, stop reading and go write content. Seriously. Most sites under 500 pages belong here.

If you have one or two Watch rows, put a monthly check on the calendar. Any Fix now row means indexing is already being hurt, whatever you call it.

Where small sites actually leak

1. Query parameters

The most common culprit. Sort, filter, tracking, and pagination parameters multiply URLs combinatorially.

Remember: a canonical tag is a hint, and Googlebot still has to fetch the URL to read it. If the problem is volume, robots.txt stops the fetch; canonicals only consolidate signals afterwards. Don't combine a robots.txt block with a noindex you need Google to see.

2. SPA routing quirks

Single-page apps create crawl problems that static sites don't have:

• Soft 404s. Your router renders a "Not found" component but the server returns 200. Every typo'd or stale URL looks like a real page. Fix: return a real 404 status from the server or edge for unknown routes, or at minimum add <meta name="robots" content="noindex"> on the not-found view.
• Hash vs history routing. /#/pricing is a single URL to Google. If you want those views indexed, use history-API routes with server-rendered or prerendered HTML.
• Links that aren't links. onClick={() => navigate('/x')} on a <div> isn't followed. Use real <a href> elements for anything you want crawled, and avoid them for state you don't.
• Infinite client-side states. Search boxes, date pickers and calendars that push every state into the URL can create endless crawl paths. Keep transient UI state out of crawlable links.
• Rendering cost. JS-heavy pages require a render pass. Prerendering or SSR for key routes removes a dependency on Google's render queue.

3. Slow or flaky servers

Crawl capacity drops when your host is slow or throws errors. A cheap shared host that spikes to 3 seconds or returns intermittent 5xx under load tells Googlebot to back off. Caching HTML at the CDN often fixes this in an afternoon.

4. Redirect chains and stale internal links

Each hop is an extra fetch. After migrations, update internal links to point directly at final URLs and keep chains to one hop.

A 20-minute check, in order

Step 6 takes ten seconds and catches a surprising number of SPA deployments.

If you'd rather not assemble this by hand, I keep a set of free checkers at riichimirza.com/tools that cover several of these steps.

What "fix now" looks like in practice

Prioritize by impact per hour:

1. Return correct status codes (404/410 for gone, 301 for moved). Cheapest, biggest win on SPAs.
2. Stop generating crawlable parameter links in templates and components.
3. Disallow pure-junk parameter patterns in robots.txt (sort orders, session IDs, internal search results).
4. Clean the sitemap so it only lists canonical, indexable, 200-status URLs.
5. Speed up HTML delivery via caching or SSR for important routes.
6. Re-check in four weeks: the ratio and the "not indexed" counts should both fall.

The honest conclusion

For a typical brochure site, blog, or portfolio under 500 pages, crawl budget is not a thing to optimize. It's a symptom you'd only notice if something else is broken. The triage above is really a test for those breakages: URL explosion, soft 404s, and slow servers. Fix them and "crawl budget" disappears as a concern on its own.

I write more about practical technical SEO for developers on the blog.

Written by Riichi Mirza.

That's why guessing is risky here. If you "fix" a real page by returning a 404, you lose a URL that should rank. If you leave a dead page returning 200, you waste crawl budget and fill the index with junk. So before I change anything, I sort each URL into a bucket. This is the order I work in, written for developers who own the stack.

Step 1: Separate the two signals

Google weighs two things for every URL:

1. The HTTP status code: what your server says.
2. The content signals: what the rendered page looks like. That means word count, a template with an empty main area, phrases like "not found" or "no results", and near-duplicate boilerplate.

A soft 404 means signal 1 says "fine" and signal 2 says "empty." Your job is to work out which signal is lying.

I export the Soft 404 URLs from Pages → Not indexed → Soft 404 and put each one into one of three buckets:

Most of the work is Bucket A, and the most common cause of Bucket A is a single-page app.

Step 2: Check whether your SPA lies about missing routes

Here's the classic setup. React, Vue or Svelte with client-side routing, served by a catch-all rule that sends index.html for every path. A visitor hits /products/does-not-exist. The server sends back 200 with the app shell. JavaScript boots, the router finds nothing, and it renders a nice "Page not found" component.

To a person, that's a 404. To Google, it's a 200 page whose rendered content says "not found." That's the textbook soft 404.

You can confirm it in about ten seconds. Request a path that can't exist:

curl -s -o /dev/null -w "%{http_code}\n" https://example.com/zzz-definitely-missing-123

If that prints 200, every typo, deleted product and stale backlink on your site is a soft 404 waiting to happen. Then use URL Inspection → Test live URL → View tested page on a reported URL. If the screenshot shows your not-found component, the content signal is right and the status code is the problem.

Fixing it in the client alone isn't enough

Some guides say to add <meta name="robots" content="noindex"> when the router misses. That keeps the page out of the index, but the status is still 200, so the URL can keep showing up in reports. The fix that works reliably is to let the server know which routes exist.

Step 3: Return real 404s from the server

Node / Express

If your routes are known (static paths or a slug lookup), check them before falling back to the shell:

import express from "express";
import path from "node:path";

const app = express();
const dist = path.resolve("dist");
const knownStatic = new Set(["/", "/about", "/pricing", "/blog"]);

app.use(express.static(dist, { index: false }));

app.get("*", async (req, res) => {
  const isKnown =
    knownStatic.has(req.path) ||
    (req.path.startsWith("/products/") &&
      (await productExists(req.path.split("/")[2])));

  res.status(isKnown ? 200 : 404).sendFile(path.join(dist, "index.html"));
});

app.listen(3000);

The shell still loads for the missing route, so your not-found component still shows. The difference is that the status code now matches what the page says. If you use SSR (Next.js, Nuxt, Remix, SvelteKit), use the framework's built-in not-found mechanism, such as notFound() or throwing a 404 from the loader, instead of rendering an empty state.

nginx

For a static SPA where you can't look up every slug, at least stop the catch-all from swallowing obvious junk such as missing assets and old file extensions:

location ~* \.(js|css|png|jpg|svg|woff2?|php|asp)$ {
    try_files $uri =404;
}

location / {
    try_files $uri $uri/ /index.html;
}

error_page 404 /404.html;

For paths that are gone for good, an explicit return 410; in a location block tells Google the page is intentionally gone. In my experience, Google drops those faster than plain 404s.

Step 4: Handle Bucket B (real but thin)

Not every soft 404 is a routing bug. The repeat offenders I see are:

• Empty search or filter pages, such as /shop?color=teal with zero results
• Category pages with no items yet
• Out-of-stock product pages stripped down to a title and a "notify me" button
• User profile pages with no activity

For each one, decide whether it deserves to rank. If it does, add real content: descriptions, related items, specs. If it doesn't, return a 404 when it's truly empty, or add noindex, and stop linking to it internally. Search result pages generally shouldn't be indexable at all.

Step 5: Clean up your sitemap

This is the step people skip, and it's often why soft 404s keep coming back. If your sitemap lists URLs that return 404, redirect, or render empty, you're asking Google to crawl problems.

A quick audit in Node:

const xml = await (await fetch("https://example.com/sitemap.xml")).text();
const urls = [...xml.matchAll(/<loc>(.*?)<\/loc>/g)].map(m => m[1]);

for (const url of urls) {
  const r = await fetch(url, { redirect: "manual" });
  if (r.status !== 200) console.log(r.status, url);
}

My rules for sitemaps:

• List only canonical URLs that return 200.
• No redirects, no noindexed pages, no parameter variations.
• Build the sitemap from the same data source as your routes, so a deleted product leaves both at the same time.
• Keep <lastmod> honest. Don't stamp every URL with today's date.

Step 6: Validate, then wait

Once you've deployed the fix, run the curl check again, run URL Inspection's live test on a few reported URLs, and then click Validate Fix in Search Console. Validation can take a couple of weeks. Bucket A URLs should move from "Soft 404" to "Not found (404)". That's the result you want: the report now matches what's really on your site.

If you'd like quick utilities for status checks and URL work, I keep a set at riichimirza.com/tools. I write more technical SEO teardowns like this one on the blog.

TL;DR

• A soft 404 means the status code and the content disagree. Work out which one is wrong.
• Test a nonsense URL. If it returns 200, your SPA catch-all is the cause.
• Fix status codes on the server (Express, SSR not-found handling, nginx). Client-side noindex is a patch, not a fix.
• Thin pages either get real content or get removed from the index.
• Your sitemap should list only live, canonical 200 URLs.

Written by Riichi Mirza

Most of these failures come from a short list of avoidable mistakes. Here they are, with what to do about each, so your next print run pays off.

1. Printing a static code that points to a URL you'll change later

This one costs more than any other. A static QR code bakes the destination URL into the pattern. If that page moves, gets renamed during a site redesign, or the campaign ends and the URL redirects to a 404, every printed piece becomes useless.

Fix it:

• Point printed codes at a short, stable URL you control, not a deep link that might change.
• Use a redirect layer so you can update the destination without reprinting. A URL shortener or a redirect on your own domain both work.
• Before you approve the proof, ask yourself: "Will this exact URL still work in two years?"

2. Making the code too small

Designers like to shrink QR codes so they don't spoil the layout. Phones are less forgiving. A code that scans fine on a monitor can fail at 1.5 cm on a business card, especially if the camera is older or the light is poor.

Fix it:

• As a rule of thumb, keep the code at least 2 × 2 cm (about 0.8 in) for handheld items.
• Scale up with distance. A simple guide is that the scanning distance divided by 10 gives you the minimum code width. A poster read from 2 meters needs a code around 20 cm wide.
• Longer URLs make denser patterns, and dense patterns need more size. Shorter links help here too.

3. Cutting into the quiet zone

The blank margin around a QR code (the "quiet zone") isn't wasted space. Scanners use it to find where the code begins. Crowd it with text, borders, or background patterns and scan rates drop.

Fix it:

• Leave a clear margin of at least four modules (four of the code's small squares) on every side.
• Don't put the code right up against a trim line, fold, or busy photo.

4. Low contrast or inverted colors

Brand teams often want the code in brand colors. That's fine within limits. Light gray on white, dark blue on black, and gold foil on cream all look elegant and scan poorly. Inverted codes (light modules on a dark background) still confuse some scanner apps.

Fix it:

• Keep the modules dark and the background light, with strong contrast.
• Test colored versions on several phones before you commit.
• Be careful with metallic inks, spot varnish, and glossy laminates. Glare can wipe out a code under shop lighting.

5. Exporting a low-resolution image

A code pulled from a screenshot or saved as a small JPEG will blur or pick up compression artifacts once it's printed. Soft module edges make scanning less reliable, and on large formats the problem is obvious.

Fix it:

• Export as SVG or high-resolution PNG. Vector formats are best for print.
• Don't stretch a code in your layout software without locking its proportions.
• Generate a fresh, clean file for each campaign rather than reusing an old asset. A free QR code generator that exports SVG makes this quick.

6. Overdoing logos and customization

A logo in the middle of the code can work, because QR codes have built-in error correction. But error correction has limits. A big logo, rounded "artistic" modules, and altered corner markers can push a code past what scanners can recover.

Fix it:

• Keep center logos small, roughly under 20–25% of the code's area.
• Use a higher error-correction level (Q or H) if you add a logo.
• Never change the three large corner squares (the finder patterns).

7. Sending scanners to a page that isn't mobile-ready

The code scans perfectly, and then the visitor lands on a slow desktop page, a pop-up, or a generic homepage that has nothing to do with the offer they just saw. You paid for the scan and lost the visitor in the next three seconds.

Fix it:

• Send every code to a dedicated, mobile-first landing page that matches the printed offer.
• Keep the page light: compressed images, minimal scripts, and a clear call to action above the fold.
• Make sure the page loads over HTTPS. Some phones warn people about insecure links.

8. No tracking, so no way to prove ROI

If every QR code across your flyers, packaging, and storefront points to the same plain URL, you can't tell which placement worked. Next quarter's print budget ends up based on guesswork.

Fix it:

• Add UTM parameters to each destination (for example utm_source=flyer&utm_medium=print&utm_campaign=spring-sale).
• Use a different code or link for each placement you want to compare.
• Check your analytics after a week. A placement with no scans is a placement you can drop.

9. Skipping the real-world test

This is the mistake behind most of the others. Teams check the code on screen, approve the proof, and send it to print. The first real test happens when a customer tries it, and by then the print run is finished.

Fix it: run this checklist on a printed proof, not a monitor:

• Scan with at least one iPhone and one Android phone
• Try the native camera app, not just a dedicated scanner app
• Test at the real viewing distance and under the real lighting
• Confirm the destination loads quickly on mobile data, not just office Wi-Fi
• Check that UTM tags appear in your analytics
• Check that a call to action sits next to the code ("Scan for 10% off", not just a bare square)

Quick pre-print checklist

Before any file goes to the printer, confirm:

1. Stable destination: a short URL or redirect you control
2. Size: at least 2 cm for handheld items, scaled up for distance
3. Quiet zone: four modules of clear space on all sides
4. Contrast: dark modules on a light background, no glare-prone finishes
5. File format: SVG or high-resolution PNG
6. Customization: a small logo, high error correction, and untouched corner markers
7. Landing page: mobile-first and matching the offer
8. Tracking: UTM parameters for each placement
9. Tested: scanned on a physical proof with multiple devices

A QR code is only worth the money if people can scan it, land somewhere useful, and you can measure the result. Getting these nine details right takes about fifteen minutes. A reprint takes weeks and costs far more.

Riichi Mirza builds free web tools at riichimirza.com.

What matters

1. 301 vs 302 — Permanent (301) redirects pass equity; temporary (302) and JS-only redirects are weaker or opaque to crawlers.
2. Interstitials / ads — Skip shorteners that show interstitial pages before the destination.
3. On-site links — Never replace your own internal links with short URLs. Link directly on your site.
4. Tracking — Short links shine for print, SMS, and social where click analytics matter.
5. Brand trust — A branded short domain usually gets better CTR than a random opaque slug.

Practical takeaway

Use shorteners for distribution and measurement, not as a ranking hack. If you need a free shortener for campaigns, I keep one at https://riichimirza.com/tools/url-shortener/.