Most corporate websites lose visibility for reasons nobody can see from the browser: pages search engines cannot reach, duplicates competing with each other, templates that render slowly, markup that says nothing. A technical SEO audit finds them. This checklist is the one we use for corporate and B2B websites — large, multilingual, often on an enterprise CMS — and it is written so that a marketing or digital team can run the first pass without an agency.
The idea
Technical SEO is not a list of tricks. It is the engineering condition of a website as seen by a crawler: can every important page be found, understood, rendered quickly and trusted? An audit checks each of those in order, prioritises what it finds by business impact, and ends with a plan someone can build — not a 200-page export.
The order matters. Fixing structured data on pages Google cannot crawl is wasted work; speeding up templates that are blocked by robots.txt changes nothing. Start at the top of this list and work down.
Why it matters
On a site with thousands of pages, the gap between what exists and what is indexed is usually where the lost traffic lives. A corporate website that has been redesigned twice, migrated once and edited by many hands over ten years accumulates redirect chains, orphaned sections, forgotten language folders and parameter URLs that dilute everything. None of it shows in the design review. All of it shows in Search Console.
In practice: the checklist
1. Crawlability
robots.txt — nothing important disallowed; staging and admin paths blocked; sitemap referenced.
XML sitemaps — present, valid, split by type, containing only canonical, indexable 200 URLs; last-modified dates real.
Crawl the site with a desktop crawler and compare the URL count with your CMS and with Search Console’s indexed pages. Three numbers that should roughly agree — and rarely do.
Orphan pages — pages in the sitemap or logs that no internal link reaches.
Crawl depth — every important page reachable within three clicks of the home page.
2. Indexation
Search Console coverage — “Crawled, not indexed” and “Discovered, not indexed” lists read page by page; they tell you what Google considers thin or duplicate.
Canonicals — self-referencing on every indexable page; consistent with sitemaps, hreflang and internal links.
Noindex — applied to search results, filters, tag archives, thank-you pages; not applied by accident to anything that earns traffic.
Parameter and faceted URLs — product filters, sort orders and tracking parameters controlled by canonicals or rules, not indexed as thousands of near-duplicates.
Pagination — crawlable and self-canonical.
3. Architecture and internal linking
URL structure — readable, stable, lowercase, no session IDs; one URL per page.
Navigation — the main sections linked from every page; important deep pages linked from hubs, footers and related-content blocks, not only from the sitemap.
Internal links — no links to redirected or broken URLs; anchor text descriptive.
Redirects — 301s, not 302s, for permanent moves; no chains longer than one hop; no loops. After a migration this is the single most common failure.
4. Rendering and JavaScript
Rendered vs. raw HTML — compare what a crawler receives with what the browser shows. Content, links and metadata injected only by client-side JavaScript may not be seen.
Lazy loading — images and content still discoverable; no infinite-scroll-only listings.
Blocked resources — CSS and JS Google needs to render the page are not disallowed.
5. Performance and Core Web Vitals
Field data — Search Console’s Core Web Vitals report and CrUX, not only lab scores; group by template.
LCP — hero images sized, compressed and preloaded; fonts subset and preloaded; no render-blocking CSS in the critical path.
INP — heavy scripts, tag managers and animation libraries deferred or removed.
CLS — image dimensions set; fonts with fallback metrics; no late-injected banners.
Caching and delivery — CDN, compression, cache headers, image formats (AVIF/WebP).
6. On-page and metadata
Titles and descriptions — unique, specific, within length; templates producing sensible defaults for thousands of product or news pages.
Headings — one H1, a logical H2/H3 structure that mirrors the content, not the design.
Images — descriptive file names and alt text where the image carries meaning.
Thin and duplicate content — near-identical pages consolidated or differentiated.
7. Structured data
Organization — name, logo, sameAs, locations, on every page via the site graph.
Page types — Article, Product, FAQPage, BreadcrumbList, JobPosting where relevant; generated from the content model so editors cannot break it.
Validation — Rich Results Test and Search Console enhancement reports; no errors, few warnings.
8. International
hreflang — every language/market version of a page references all others and itself; return links consistent; x-default set.
Structure — one clear pattern (subfolder, subdomain or ccTLD) applied everywhere.
Untranslated pages — not published as duplicates of the source language.
9. Security and hygiene
HTTPS everywhere, one canonical host (www or not), HTTP redirected.
Error handling — real 404 status for missing pages, not soft 404s; a useful 404 page.
Old properties — retired domains, staging sites and legacy microsites redirected or removed from the index.
10. Monitoring
Search Console — coverage, enhancements and Core Web Vitals reviewed monthly; alerts on spikes in errors.
Log files — where available, what crawlers actually fetch and how often.
Change control — every template, CMS or hosting change checked against this list before release.
What to do
Run sections 1–3 first; they decide whether anything else matters. Put the findings in one prioritised document with three columns: impact, effort, owner. Fix redirects, canonicals and blocked pages before touching performance. Then treat the rest as engineering work with releases and verification — because that is what it is.
If the fixes require changes to templates, the CMS or the front-end, they belong with whoever engineers the website. That is why we do technical SEO as part of building and maintaining sites rather than as a separate report — see our technical SEO agency page, or read how to choose a technical SEO agency.
FAQ
How often should a corporate website be audited?
A full audit once a year and before any redesign or migration; sections 1–3 and Core Web Vitals reviewed quarterly, or after any significant release.
Which tools do you need?
A desktop crawler, Google Search Console, PageSpeed Insights or CrUX data, the Rich Results Test and — for large sites — access to server logs. Most of the value comes from reading the results carefully, not from the tool.
Can an audit be done without developer access?
The audit, yes. The fixes, rarely. Budget for engineering time from the start.
Want the audit done for you? Request a technical SEO audit — we deliver a prioritised, buildable plan, and we can implement it.