Technical SEO
A Technical SEO Audit for Production Websites
A production-first audit method for crawl access, status codes, canonicals, rendering, sitemaps, structured data, internal links, and legacy URL cleanup.
Author: Fahad Bin Shakir · Published: · Updated: · 12 min read
Introduction
Technical SEO begins with what a crawler receives from the public URL, not what a route component intends to render. A repository can contain perfect metadata while a CDN serves an old document, a deployment flag emits noindex, or a history fallback returns 200 for every unknown path.
A useful audit connects the live HTTP surface to the application source and deployment configuration. It classifies problems by their effect on discovery, indexing, duplication, and user trust, then verifies the correction at the same public URL where the issue appeared.
Build a production URL inventory
Crawl from the homepage, but also collect URLs from XML sitemaps, Search Console, analytics landing pages, server logs, backlinks, old CMS exports, and search-engine results. Navigation alone misses orphaned legacy pages and files that remain reachable through historical links.
For each URL record status, redirect target, title, description, robots directive, canonical, H1, rendered content, structured data, internal inlinks, and sitemap membership. Group templates so a systemic defect can be fixed once and sampled across representative pages.
Make status codes truthful
A valid page should return 200. A moved resource should use a direct 301 or 308 to its closest replacement. Removed demo content without a replacement can return 410, while unknown resources return 404. The response body may offer navigation, but it must not disguise the status as 200.
Avoid redirecting all unknown paths to the homepage. That creates confusing user journeys and soft-404 signals. Test protocol, host, slash, case, and encoded variants and remove redirect chains where the platform permits.
Align crawl rules, index directives, and canonicals
robots.txt controls crawling, not guaranteed de-indexing. Search engines need to fetch a removed URL to see its 404, 410, or noindex response. Keep production assets and indexable documents crawlable, and protect staging with authentication or a fail-closed noindex configuration.
Use a self-referencing canonical on each indexable representation and normalize to one HTTPS host. A canonical is a hint, so internal links, sitemaps, redirects, and alternate versions should agree. Do not canonicalize an error page or a materially different page to the homepage.
Verify crawler-visible content and metadata
Inspect the response HTML before JavaScript. It should identify the page with a unique title, useful description, canonical, robots directive, primary heading, and enough main content to understand the purpose. Client-side updates can improve SPA navigation, but they should not be the only place critical metadata exists.
Structured data must describe content that visitors can see. Use the most specific accurate type, stable identifiers, valid dates, and real authorship. Do not add ratings, reviews, organizations, credentials, or achievements that are not supported by the page.
Keep sitemaps and internal links selective
A sitemap should list canonical, indexable, 200-status URLs. Exclude redirects, errors, APIs, utilities, thin duplicates, and noindex pages. Accurate lastmod values should reflect a meaningful content change rather than the time the sitemap happened to rebuild.
Important pages need descriptive internal links from relevant content. Build clear navigation, breadcrumbs, related reading, and contextual links without repeating the same optimized phrase everywhere. An orphaned article in a sitemap is technically discoverable but poorly integrated for people.
Close legacy and deployment gaps
Search for old CMS routes, sample posts, feeds, author archives, attachments, staging hosts, and template phrases. Remove the source, then return the chosen 301, 404, or 410. A Search Console removal can temporarily hide an urgent result, but the permanent HTTP behavior must already be correct.
After deployment, recrawl the public domain, validate sitemap URLs, inspect headers, render major templates, and test an unknown route. Annotate what still requires Search Console or hosting-account access. A build passing locally is an input to production validation, not the final result.
Deployment checklist
- Combine crawl, sitemap, search, logs, analytics, and legacy-source URLs.
- Record live status, redirect, metadata, canonical, H1, and indexability.
- Return truthful 200, 301, 404, and 410 responses without soft 404s.
- Keep robots, noindex, canonicals, internal links, and sitemap signals aligned.
- Provide meaningful response HTML before client-side enhancement.
- Use only structured data supported by visible facts.
- Remove legacy sources and verify the same public URLs after release.
- Separate code fixes from Search Console and hosting-account actions.