SEO
What a technical SEO audit should actually uncover
A technical SEO audit should explain why important URLs are hard to discover, hard to index or hard to trust. A crawl dump without commercial priority is just inventory.
Pixoflix · 29 August 2026
Guide
What a technical SEO audit should actually uncover
Most companies that ask for a technical SEO audit already have a report. A plugin produced 140 pages of warnings. A crawl tool listed thousands of 404s. An agency deck showed red, amber and green. Nobody can say which finding would change pipeline this quarter.
A technical audit is not a completeness contest. It is a diagnosis of whether search engines can find, understand and trust the URLs that create demand. If the output cannot be sequenced by a marketer and an engineer in the same meeting, it is not finished.
Why plugin reports are not audits
Site health plugins and generic crawlers are useful sensors. They are bad editors. They treat a missing alt attribute on a footer icon with the same emotional weight as a parameterised faceted URL that is absorbing crawl. They also cannot see your commercial map: which templates close deals, which markets you are entering, which locales are real.
An SEO Audit at Pixoflix still uses crawls, log-aware sampling where available, and Search Console. The difference is the first artefact: a short list of money URLs and the templates behind them. Everything else is judged against that list.
Crawl and discovery
Start with whether a crawler can reach the pages you care about without wasting budget on noise.
- robots.txt blocking resources or environments that should be public, or leaving staging open.
- XML sitemaps that omit canonical commercial URLs, include noindex URLs, or list 404s.
- Navigation and internal links that never reach new industry or integration pages.
- Infinite spaces: filters, calendars, search results, paginated archives with weak rel rules.
- Orphan URLs that exist in a sitemap or ads but have no in-template path from the home page.
On WordPress, discovery problems often come from archive combinations (category + tag + author + pagination) and from plugins that mint feeds or parameter URLs. WordPress SEO is usually the implementation layer once the rules are decided.
Indexation and canonicals
Discovery without indexation is a museum. You want the intended URL in the index and the duplicates out.
- Confirm what Search Console says is indexed versus what the CMS thinks is published.
- Check noindex, nofollow and X-Robots-Tag on templates, not only on a few hand-picked pages.
- Read canonicals on paginated series, HTTPS/HTTP pairs, www pairs, and trailing-slash variants.
- Inspect parameter handling. A session id or sort order should not create a second product URL.
- Treat HTTP 301 as a tool with a destination, not a way to hide a messy sitemap. Chains and loops are findings.
- Know when HTTP 410 is more honest than a soft 404 that keeps a dead URL half-alive.
Canonical mistakes are especially expensive before a Website Redesign. If the new templates launch without a redirect map from the old money URLs, you will spend the next quarter explaining a traffic dip that was avoidable.
Information architecture as a technical problem
IA is not only a UX concern. Depth, siloing and repeating page types change how PageRank-like attention and crawler attention move. A service business with twelve thin location pages and one real service page is a technical and content problem at the same time.
The audit should say whether the current tree can support Increase Organic Traffic without spawning near-duplicate landing pages. If every campaign needs a new root URL because the templates cannot express a use case, you do not have an architecture. You have a pile.
Template-level issues beat one-off page tweaks
Fixing title tags on ten pages while the product template still renders empty H1s is theatre. Look at the templates that generate volume.
| Template | What to inspect | Typical failure |
|---|---|---|
| Home and hub | Unique intro, child links, crawl paths | Hub is a thin teaser with no internal links |
| Service or category | H1, copy block, facets, pagination | Identical copy across dozens of URLs |
| Product or location | Canonical, variants, structured data | Variant URLs compete with the parent |
| Article | Author, dates, related links | Tag archives outrank the article |
| Utility | Index policy | Thank-you and search pages are indexed |
Structured data without theatre
Markup should describe what is on the page. FAQ schema on a page with no FAQs, Product schema on a service brochure, or Review schema with invented ratings are liabilities. A technical audit should remove unsafe markup as readily as it adds missing markup.
Performance as an indexing constraint
Core Web Vitals are not a design trophy. They are field and lab signals that affect whether a page is pleasant enough to keep, and they correlate with how heavy a template is for users and bots.
Use the published thresholds as a shared language, not as a promise of ranking. Largest Contentful Paint at or below 2.5 seconds, Interaction to Next Paint at or below 200 milliseconds, and Cumulative Layout Shift at or below 0.1 are the current “good” bands. An audit should say which template misses them, which third party is responsible, and whether the fix is image policy, theme JavaScript, or hosting.
Do not report a single lab URL as if it were the site. Template sampling beats homepage heroics.
Rendering and JavaScript
If primary content or links appear only after client-side rendering, verify what Googlebot actually receives. Marketing sites on WordPress should not need a single-page-app crawl story. If they do, that is a finding about the stack, not a badge of sophistication.
Accessibility-adjacent checks that belong in the same pass
Technical SEO and accessibility share HTML quality. Heading order, link names, and form labels affect both users and extraction. WCAG 2.2 is the reference we use when those issues appear in templates. An SEO audit should not pretend to be a full accessibility conformance claim. It should not ignore heading soup either.
What the output should look like
Technical SEO work is only useful if someone can implement it. Group findings into: stop the bleeding (indexation leaks, broken money URLs), recover equity (redirects, canonicals), then improve templates (performance, IA, internal links). Attach owners. Date the crawl and the Search Console window you used. If a date is not known, do not invent one.
If a finding cannot be tied to a URL pattern and a next action, it belongs in the appendix or it belongs in the bin.
Content strategy still matters. A clean index of empty pages will not grow a business. The audit should say where the technical system is the bottleneck and where the next move is SEO Content Strategy or a redesign. Those are different programmes. Mixing them in one vague “SEO retainer” is how teams stay busy and stay stuck.