Iriscale
ARTICLE

How to Run a Technical SEO Audit (And Why Iriscale Doesn't Do This For You)

Let’s start with the thing this guide exists to say plainly: Iriscale does not run technical SEO audits, fix crawl errors, or implement canonical tags. If you came here hoping a content platform would quietly handle your indexing problems in the background, it’s important you know that now rather than three months into a subscription. Technical SEO is genuinely developer and infrastructure work — robots.txt, server response codes, JavaScript rendering, canonical implementation — and it lives in your codebase, not in a content tool.

What this guide does give you: a real, step-by-step technical audit checklist you or your development team can run, grounded in Google’s own documentation rather than vendor marketing. If you’re evaluating whether Iriscale is the right platform for your needs, understanding this boundary clearly is more useful than a vague promise that “AI handles it” — because it doesn’t, here or anywhere else without a human developer in the loop.

What Does a Technical SEO Audit Actually Answer?

One question: can search engines efficiently crawl, understand, and index the pages that matter — at a quality level that meets modern performance expectations? The symptoms when the answer is no are familiar to anyone who’s dealt with them: important pages sitting unindexed, rankings plateauing for no visible content reason, sudden spikes in “Excluded” URLs in Search Console, or performance regressions quietly eroding conversion rates.

Google is explicit that crawl budget isn’t a direct ranking factor, but it does affect how quickly and completely your pages get discovered and indexed — especially on large or frequently updated sites. Core Web Vitals are officially minor ranking signals, but they’re real enough to break ties in competitive results and they compound directly with user experience and conversion.

The Audit Checklist

1. Crawlability: robots.txt and Crawl Waste

Confirm robots.txt exists at your domain root and validate its syntax — User-agent, Disallow, Allow directives, kept well under the 500KB size Google will process. Critically: robots.txt controls crawling, not indexing. Using it to try to de-index a page is a common and persistent mistake — a disallowed page can still get indexed if enough signals point to it elsewhere; noindex is the correct tool for that job.

Identify crawl waste — parameter URLs, internal search result pages, faceted navigation combinations, low-value near-duplicates. Google defines crawl budget as crawl capacity limit plus crawl demand, and waste on either side slows discovery of the pages that actually matter.

Fix first: 5xx errors and unstable server responses, which directly reduce how much Google is willing to crawl; redirect chains and loops, which waste crawl resources for no benefit; and genuinely low-value URL patterns blocked deliberately in robots.txt — never content you actually want indexed.

2. Indexation: Search Console Coverage and Canonical Alignment

Review your Index Coverage report’s buckets — Error, Valid with warning, Valid, Excluded — and investigate the common Excluded reasons specifically: duplicates without a clear canonical, pages blocked by robots, and “discovered but not indexed,” which usually points back to a quality or technical review being needed.

Verify your canonical signals are actually consistent. Google treats canonical tags as a strong signal, not an absolute directive — it evaluates multiple signals site-wide and can choose a different canonical than the one you specified if your other signals (internal links, sitemap, redirects) disagree with your tag.

Fix first: pages that should rank but are blocked, unintentionally noindexed, or sitting in Error status; and duplicate URL variants where Google’s chosen canonical doesn’t match your intended one — usually caused by inconsistent internal linking pointing at multiple versions of the same content.

3. XML Sitemap: Keep It a Clean Source of Truth

Respect the technical limits — 50,000 URLs or 50MB per sitemap file, splitting into a sitemap index if you exceed either. Include only canonical, indexable URLs that return a 200 status and aren’t blocked — never a dump of everything your CMS is technically capable of generating.

Fix first: remove any URLs from your sitemap that redirect, 404, aren’t canonical, or are blocked by robots.txt. Your sitemap should read as a curated shortlist of what deserves indexing, not an unfiltered export.

4. Site Speed and Core Web Vitals

Current thresholds: LCP (Largest Contentful Paint) at 2.5 seconds or better, CLS (Cumulative Layout Shift) at 0.10 or better, and INP (Interaction to Next Paint) at 200 milliseconds or better. Critically, evaluate real-user field data, not just lab test scores — pages routinely pass in the lab and fail in the field, and field data is what actually matters for ranking and for real users.

Identify template-level offenders rather than chasing individual pages: heavy hero images, render-blocking scripts, font-swapping causing layout shift, and third-party tag bloat are almost always template or platform issues that show up identically across every page using that template.

Fix first: LCP issues on your highest-traffic templates (home, category, product, top content); INP regressions traceable to JavaScript event handling, often from a specific theme or plugin; and CLS caused by late-loading images or ads missing explicit width and height attributes.

5. Mobile Usability

Google indexes primarily from the mobile version of your pages — mobile-first indexing means technical parity between mobile and desktop isn’t a nice-to-have, it’s what Google actually sees. Confirm your responsive layout serves the same primary content and structured data on both, that your viewport is configured correctly, and that you’re not running intrusive overlays that degrade mobile UX.

Fix first: content present on desktop but missing or hidden on mobile, which can genuinely reduce how Google assesses the page’s relevance; and broken tap targets, overflow issues, or blocked resources preventing full mobile rendering.

6. Structured Data

Use supported schema types via JSON-LD, which Google recommends for ease of implementation over microdata alternatives. Validate that your markup actually matches your visible content — mismatched price or availability data between schema and the page itself is a common, easily-caught error that undermines trust signals.

Be clear-eyed about what structured data does: rich results can meaningfully increase visibility and click-through rate, but they do not directly improve rankings. It’s a presentation and trust layer, not a ranking lever on its own.

Fix first: invalid markup on your highest-traffic templates (Product, Article, and similar), and any mismatch between what your schema claims and what your page actually shows.

7. Internal Linking

Important pages should sit within roughly three clicks of your homepage. Use descriptive anchor text rather than repetitive “click here” links, and keep link volume on any single page reasonable — an excessive link count dilutes the value each individual link passes.

Fix first: orphan pages with no internal links pointing to them at all, and commercially important pages (category hubs, product guides) that are technically live but buried too deep in your architecture to be found easily.

8. Duplicate Content and Canonicalization

Identify duplicate URL patterns systematically: parameter variants, pagination duplicates, tracking-code URLs, HTTP versus HTTPS, www versus non-www. Cross-check your canonical hints — the HTML tag, your redirect structure, and your sitemap — for internal consistency, and in Search Console specifically review any “Google chose a different canonical than the user” flags.

Fix first: enforce one preferred URL through redirects and consistent internal linking, and canonicalize near-duplicate faceted collections to clean category pages where it makes sense. Canonicalization succeeds when every signal agrees — the tag, the links, the sitemap, and the redirects all pointing the same direction — not when any single one of them is technically correct in isolation.

How Should You Prioritize the Findings?

Four tiers, in order of impact. Indexation blockers first — pages you genuinely want indexed but aren’t; your Search Console Coverage report is the triage map for this tier. Crawl efficiency threats second — 5xx errors, redirect chains, and URL traps that waste crawl capacity and slow discovery of everything else. Template-level performance third — LCP, INP, and CLS issues fixed at the template level move faster and further than page-by-page tweaks ever will. Enhancers last — structured data eligibility and internal linking refinements that improve visibility and reinforce architecture, valuable but lower urgency than the first three tiers.

Common Mistakes Worth Naming Directly

Using robots.txt to try to de-index pages, when it only controls crawling. Submitting sitemaps padded with redirects, blocked URLs, and non-canonical pages, which dilutes the sitemap’s usefulness as a signal. Fixing Core Web Vitals page by page instead of recognizing it’s almost always a template or system-level problem. Setting canonical tags that conflict with your actual internal linking pattern — Google will notice the disagreement and may choose differently than you intended. And ignoring mobile parity entirely, when mobile-first indexing means a mobile gap is an SEO gap, full stop.

Most technical SEO failures aren’t exotic edge cases. They’re consistency failures — one signal disagreeing with another.

Why Doesn’t Iriscale Automate This?

Because it’s genuinely a different discipline requiring genuinely different access. Fixing a 5xx error, correcting a canonical tag, or resolving a JavaScript rendering problem all require changes to your actual codebase and server configuration — access and expertise that live with your developers, not in a content platform’s dashboard, regardless of how the platform is marketed.

What Iriscale does instead, honestly stated: Content Architecture plans your site’s information hierarchy and internal linking structure before pages get built, which is the strategic layer that prevents a meaningful share of technical debt from accumulating in the first place — orphan pages, duplicate near-identical content, and unclear hierarchy are often symptoms of no upstream planning, not just execution bugs. Topic Strategy and the Articles Hub keep your published content itself free of the thin-content and duplication patterns that show up as technical symptoms downstream. And Search Ranking Intelligence will show you when something’s wrong — a page that should rank losing visibility, a cluster underperforming its siblings — even though the platform won’t tell you it’s specifically a crawl-budget or canonical-tag issue underneath. That diagnostic step is where this checklist comes in, run by you or handed to your development team with the specific symptom already identified.

The honest division of labor: Iriscale helps you avoid creating technical debt through better upstream planning, and helps you notice its downstream symptoms through measurement. The actual technical remediation — the item-by-item work in this checklist — stays with your developers, every time, on every platform, regardless of what any vendor’s marketing implies.

Frequently Asked Questions

If Iriscale doesn’t fix technical SEO, what’s the value of using it alongside a technical audit?

The upstream and downstream layers this checklist doesn’t cover. A technical audit is a snapshot — it finds today’s crawl errors and canonical conflicts. It doesn’t prevent tomorrow’s, and it doesn’t tell you which of your content decisions are quietly generating the technical debt in the first place. Iriscale’s Content Architecture plans your site hierarchy before pages exist, which structurally prevents a real share of the orphan-page and duplicate-content problems this checklist has to find and fix after the fact. And Search Ranking Intelligence gives you the ongoing visibility layer — noticing a ranking or indexation problem the week it starts, across Google and five AI engines — rather than discovering it at your next scheduled technical audit months later. Think of it as: Iriscale reduces how often you need this checklist and shortens how long problems go unnoticed between audits; it doesn’t replace running the checklist itself.

How often should we run a full technical SEO audit?

Quarterly for most sites, with lightweight monthly spot-checks on your highest-traffic templates in between. Large or frequently-changing sites — active ecommerce catalogs, sites with regular CMS or template updates — benefit from more frequent monitoring of the crawl and indexation signals specifically, since those degrade faster than content quality typically does. The trigger that should prompt an audit outside your regular cadence: any major site change — a migration, a template redesign, a significant CMS update — because these are exactly the events most likely to introduce the consistency failures (conflicting canonicals, broken redirects, changed URL structures) this checklist is built to catch.

Can we run this checklist ourselves without hiring a technical SEO specialist?

For a meaningful portion of it, yes, particularly the diagnostic steps — Search Console review, sitemap auditing, structured data validation are all accessible without deep technical expertise. Where you’ll likely need developer involvement: actually implementing fixes for server errors, JavaScript rendering issues, canonical tag corrections in your codebase, and any Core Web Vitals work touching your site’s actual code or infrastructure. A workable model for a lean team: someone in marketing or SEO runs the diagnostic checklist monthly or quarterly, documents specific, concrete findings (not “the site is slow” but “LCP on the product template is 4.2 seconds, caused by an unoptimized hero image”), and hands that specific list to developers rather than a vague request to “look into SEO.” Specific findings get prioritized and fixed; vague requests get deprioritized indefinitely.

Related Reading


© 2026 Iriscale · iriscale.com · AI-Powered Growth Marketing for B2B SaaS