Audyt Techniczny SEO

A technical SEO audit is not a checklist of meta tags and status codes. I treat it as a health check on the infrastructure that determines whether Google can crawl, render, and index your content. The goal is to find the bottlenecks that stop search engines from seeing what your users see.

Most audits I opened early in my career were automated reports: thirty pages of warnings about missing alt text, duplicate titles, and slow page speeds. Those have value, but they miss the deeper problems. A single misconfigured canonical tag can nullify months of content work. A robots.txt file that accidentally blocks JavaScript can cripple rendering for an entire site. I have seen both happen.

What I do now: I start with the crawl path. Can Googlebot reach every significant page without hitting a redirect chain or a noindex directive? Then I check rendering. If the site relies on JavaScript, can Google actually execute it? I use the URL Inspection Tool in Search Console to see what Google rendered, not what I think it renders. Finally, I look at indexation consistency. The pages I expect in the index should match the pages Google reports in the coverage report. When they diverge by more than 20%, something is broken.

This plain-English shift – from symptom check to infrastructure diagnosis – changed how I prioritise fixes. A missing H1 is cosmetic. A broken canonical chain is structural.

A technical audit matters most when a change happens. Not when traffic drops – by then the damage is done. I run audits proactively before and after any significant site modification: a CMS migration, a domain move, a change in URL structure, a switch to a new CDN.

Take a client who moved from WordPress to a headless CMS. Before the migration, the site had 15,000 indexed pages. Afterwards, it dropped to 2,000. A quick audit revealed that the new setup was serving a blank HTML shell for most pages because the JavaScript rendering was not completing within Google's budget. The solution: implement server-side rendering for critical content. That fix came from an audit, not from keyword research.

Another scenario: I audit sites that have been running the same [technical SEO](/technical-seo/) setup for three years. Google changes its rendering pipeline, updates its [Core Web Vitals](/core-web-vitals/) requirements, or introduces a new [directive](/directive/). What worked in 2021 may not work today. An audit surfaces those gaps.

I also audit before launching a new section. Adding a blog, a product category, or a tool often means new parameter patterns, new query strings, or new canonical choices. An audit catches the [duplicate content](/duplicate-content/) that would otherwise emerge when two URLs serve the same content. I set a rule: every new section gets a crawl before it goes live. That has saved me more rework than any other practice.

I used to believe a technical audit was a one-time activity. Do it once, fix the issues, and move on to content and links. I was wrong.

The mistake came from treating the audit as a static report. I would run a tool, generate a list of 50 issues, fix the top 10, and declare the site healthy. Six months later, the same issues reappeared because the root cause – an internal CMS quirk that regenerated broken URLs – was never addressed. Now I schedule recurring audits. Even a lightweight monthly crawl catches regressions that a one-off would miss.

I also over-relied on automated crawlers. They flag things like missing titles and broken links reliably, but they miss behavioural problems: a [canonical tag](/canonical-tag/) that points to a URL that does not exist, a [sitemap](/sitemap/) that includes non-canonical pages, a [robots.txt](/robots-txt/) that blocks a subfolder containing images but not the HTML. Those require manual checks. I now spend an hour per audit on manual verification using Search Console, View Source, and curl commands. That hour finds the bugs that tools shrug at.

A third miss: ignoring the server log. Early audits only looked at crawl data from tools that mimic Googlebot. Real Googlebot behaviour lives in server logs – which user-agent hit what IP, which URLs returned 500s, how often a crawl of an AJAX endpoint timed out. I did not look at logs for the first two years. Now I pull the last 30 days of logs for every audit. The insight ratio is higher than any tool report.