By Miguel Ángel Jiménez, Head of SEO at Gecko Studio
There are websites that have been losing positions for months without anyone having changed a single line of content. Traffic falls gradually, pages that once appeared in the top spot slide to second and third, and the explanation lies not in the copy or the titles. It lies in the layer that is invisible when you browse: the code, the server, the configuration.
A technical SEO audit is the diagnosis of that layer. It reviews how Google accesses the site, what it can read and what it cannot, how quickly it processes it, and whether there are contradictions in the signals being sent to it. Without that prior diagnosis, any content or link-building work is built on a foundation that may already be cracked.
This article covers the main blocks of a technical audit — indexation and crawling, Core Web Vitals, canonicals, redirects, server errors — and includes a dedicated section on WordPress, where the majority of the problems we see in our client portfolio are concentrated. All illustrated with a real anonymised case: figures from an actual audit, with no identifiable names or domains.
If you want to understand first how the technical layer fits within a complete SEO audit, start with the SEO audit guide. If you already have the broader framework clear and want to go deeper into the technical layer, you are in the right place.
What a technical SEO audit analyses (exactly)
A technical audit does not review page content or keyword strategy: that falls to on-page SEO analysis. It focuses on the infrastructure: everything that determines whether Google can find pages, read them correctly, and evaluate them without friction.
The blocks it covers are five for a standard single-language website:
- Crawling and indexation — can Google enter each URL and does it decide to include it in the index?
- Core Web Vitals and speed — how fast does the page load under the real conditions of a user?
- Canonicals and duplicates — does Google know which is the "original" version of each piece of content?
- Redirects — are they correct, direct, and free of unnecessary chains?
- Server errors — does the server respond without errors or timeouts that eat into the crawl budget?
On multilingual websites a sixth block is added — hreflang and internationalisation — which we cover in the article on international SEO audits. For a single-language site like the one in the case analysed here, that block simply does not apply and is not treated as a fault: it is a module that does not exist because there are no language versions to coordinate.
Each of these blocks can be working well, poorly, or at an intermediate point that produces no immediate symptoms but erodes performance over time. The job of the audit is to quantify exactly what state each one is in and what impact it has on the whole.
The real case: a car rental company with 68/100 on mobile
To keep technical problems concrete rather than abstract, we illustrate them with real data from an audit in our portfolio. The site belongs to a car rental company, with a single-language website in Spanish. We have removed the name, the domain, and any identifiable URL. The figures are those of the real project.
The most striking data point is not any specific error: it is that months before the audit, the site scored 98–99 out of 100 in PageSpeed Insights for mobile. By the time of the analysis it had dropped to 68. There had been no change to the content or the strategy: there had been a theme update and a set of plugins that, silently, had completely degraded the technical performance. The technical scorecard at the time of the audit:
Text equivalent (the same data as the chart):
| Technical metric | Real value | Threshold or reference | Status |
|---|---|---|---|
| Mobile CWV (PageSpeed score) | 68/100 | ≥90 = good | Fails |
| Mobile LCP | 3.2 s | <2.5 s = good | Fails |
| Mobile CLS | 0.150 | <0.1 = good | Fails |
| Mobile INP | 280 ms | <200 ms = good | Fails |
| Desktop CWV (PageSpeed score) | 82/100 | ≥90 = good | Passes / improvable |
| Desktop LCP | 1.8 s | <2.5 s = good | Passes |
| Desktop CLS | 0.08 | <0.1 = good | Passes |
| Historical mobile score (before change) | 98–99/100 | — | Reference |
| 200 pages (crawl) | 907 | — | OK |
| 301 redirects (correct) | 24 | Check for chains | Review |
| Avoidable 302 redirects | 35 | 0 (convert to 301) | Fix |
| 404 errors | 2 | 0 on linked URLs | Low / review |
| Timeouts (crawl) | 4 | 0 | Low / monitor |
| Crawled, not indexed (GSC) | 481 of 750 | As few as possible | Critical |
| Not found (GSC) | 63 | 0 | Review |
| Noindex (GSC) | 45 | Intentional only | Review |
| Duplicate canonical (GSC) | 28 | 0 | Fix |
| Duplicate content (GSC) | 3 | 0 | Low / review |
| Hreflang | Not applicable | Single-language site | — |
This is the starting state. The following sections explain what each block means, why it matters, and what actions it produces.
Crawling and indexation: when Google crawls but does not index
Before ranking, a page has to exist for Google. The process is sequential: first Google's robot visits the URL (crawling), then it decides whether to include it in its index (indexation), and only then can it appear in search results. A problem at any point in that chain breaks the process.
In the case analysed, Google Search Console showed 481 pages in "crawled, currently not indexed" status out of a total of 750 crawled URLs: nearly two thirds of the site that Google visits but does not include in the index. The most common reasons:
- Low-quality or duplicate content — pages with little original content, URL variations with different parameters, or internal search filter pages that automatically generate duplicates.
- Contradictory signals — a page has no
noindextag, but its canonical points to a different URL. Google decides not to index it because it understands the "original" is the other one. - Systematic thin content — listing or category pages with very few entries that Google considers insufficient for the user.
Working out which of those reasons accounts for the bulk of the 481 exclusions is one of the first tasks of the audit. In this case, the 28 "duplicate canonical" in GSC and the pages generated by the site's filter and parameter structure explained the majority. The solution is not to "force" indexation, but to eliminate contradictory signals and consolidate dispersed content.
There are also 63 not found (URLs Google knows about but that have disappeared) and 45 noindex entries worth reviewing: some are intentional (internal management pages), others are not. The 4 crawl timeouts, while a low number, deserve attention because each timeout is wasted crawl budget.
Core Web Vitals: the silent degradation after updating WordPress
Core Web Vitals are the set of user experience metrics that Google uses as a ranking signal. They do not measure "speed" in the abstract: they measure three specific things with defined thresholds — four in the case of the INP interactivity metric, which Google incorporated as an official signal in 2024.
The most revealing data point in this case is not the current value: it is the trajectory. Months before the audit, the site reached 98–99 points out of 100 on mobile. The server had not changed, the content had not changed: there had been a theme update and a set of additional plugins installed during that period. The result was a 30-point collapse in the mobile score. This is the most common pattern of technical degradation in WordPress, and the hardest to catch in time because it happens gradually and without alerts.
LCP (Largest Contentful Paint) measures how long it takes for the main visible element of the page to appear — typically the header image or the largest heading. The good threshold is under 2.5 seconds. In the case analysed, the mobile LCP was 3.2 seconds, exceeding that limit. The usual culprit on car rental sites is the fleet imagery: high-resolution photographs uploaded unoptimised, downloaded in full before the browser can show the user anything relevant.
CLS (Cumulative Layout Shift) measures how much the on-screen content shifts while loading. A CLS of 0.150 (good threshold: below 0.1) indicates that elements are moving during load: typically images without defined dimensions in the HTML, promotional banners that appear late and push text down, or price-comparison widgets that render after the rest of the page.
INP (Interaction to Next Paint) measures how long the page takes to respond visually to a user action — a click, a tap on screen. At 280 ms (good threshold: below 200 ms), the site is in the failing zone. This occurs when third-party scripts block the main thread: typically tracking integrations, real-time booking widgets, or comparison scripts that execute synchronously.
The gap between mobile performance (68/100) and desktop (82/100, with all indicators in the green) is diagnostic in itself. It means the problem is not the server — if it were slow, it would affect both platforms equally. The cause lies in how resources are served to the device: images that are not resized for mobile, scripts that block rendering and go unnoticed on desktop because the hardware is more powerful, and third-party resources that load regardless of whether they are visible on a small screen.
The figure that matters for rankings is this: since 2021, Google has used field data from real users (the Chrome User Experience Report) to assess Core Web Vitals, not just PageSpeed lab data. If real users of the site on mobile are experiencing an LCP of 3.2 seconds and an INP of 280 ms, that is what Google is measuring. There is no way to dress up those numbers without actually improving real performance.
Canonicals and "duplicate canonical": when Google picks a different URL from the one declared
A canonical is an HTML tag that tells Google: "of all the possible versions of this URL, this is the one that counts." Its function is to resolve the duplicates problem: the same page accessible from multiple URLs (with and without www, with and without a trailing slash, over HTTP and HTTPS, with session or campaign parameters appended).
In the case analysed, the crawl detected 3 pages with cross-canonicals. Upon review, all three were technically correct: pages that consolidate variants with UTM parameters from advertising campaigns towards the clean URL. These are not a problem.
The real problem is in GSC: 28 pages in "duplicate canonical" status. This means something different from the crawl's cross-canonicals: here Google has decided that the canonical declared in the code is not the one it will respect. It has chosen a different URL as the "original". The most frequent reasons for this behaviour:
- Contradictory signals between canonical and internal linking — the page declares a canonical to itself, but internal links point predominantly to a variant with parameters or a different structure. Google follows internal links as an authority signal and may override the declared canonical.
- Insufficiently differentiated content — when two URLs have very similar content, Google may decide which to index independently of what the canonical says.
- Redirects that create confusion — a URL with a declared canonical that also redirects (or whose destination redirects) produces an ambiguous signal that Google resolves on its own terms.
The "28 duplicate canonical" figure in GSC is the most direct symptom that there is a contradictory-signals problem on the site. It is not a one-off technical configuration error: it is a discrepancy between what the site tells Google and what Google observes when it crawls it. Resolving it requires auditing each of those 28 pages to identify which signal is overriding the declared canonical.
Redirects: why 302s cost more than they appear to
A well-executed redirect transfers the authority of the old URL to the new one. The type of redirect matters: a 301 is permanent and transfers authority; a 302 is temporary and, in theory, does not transfer authority because it signals to Google that the original URL will become accessible again at some point.
In the case analysed, the crawl found 35 redirects returning 302 that should be 301. This happens frequently on sites where someone set up redirects some time ago, marked them as temporary by mistake or because "that's how the system did it", and nobody reviewed them afterwards. The impact is twofold:
- Potential authority loss — external links pointing to URLs that redirect via 302 may not be correctly passing their link equity to the destination URL.
- Temporariness signal on permanent URLs — if the site's URL structure is already settled, there is no reason to keep redirects marked as temporary; Google may decide the original URL "will return" and continue crawling both.
The fix is technically trivial: change the response code from 302 to 301 on the server or in the redirect manager. The audit work is identifying which of those 35 URLs carry external or internal links worth prioritising, so the change is made where the impact is greatest.
WordPress: the most common technical issues on the world's most widely used platform
WordPress powers approximately 43% of websites worldwide. It also concentrates a high proportion of the technical SEO problems we diagnose in our portfolio — not because the platform itself is deficient, but because its plugin ecosystem and configuration flexibility allow combinations that work individually and break things collectively. The car rental case — with a degradation from 98–99 to 68 points on mobile after an update — is the most representative pattern.
This section draws on verified technical knowledge of the most frequent failure patterns in audited WordPress sites; no additional figures have been invented for the case.
The theme change nobody audited
A theme change in WordPress is not merely a visual change. The theme controls how fonts, scripts, and styles are loaded. A poorly coded theme can load dozens of additional CSS and JavaScript files, include Google Fonts synchronously, add animation or slider scripts that block rendering, or generate elements without defined dimensions that push up CLS. In the case analysed, the 30-point degradation happened through exactly this mechanism: the new theme loaded more resources, and did so less efficiently than the previous one.
The good practice is not to avoid theme changes, but to measure before and after. PageSpeed Insights takes under a minute to produce a number. If the number drops, the theme change carries a technical cost that has to be decided: accept it, or optimise before publishing.
The checkbox nobody remembers ticking
WordPress includes under Settings → Reading an option labelled "Discourage search engines from indexing this site." It is intended for sites under construction. If it is active in production, the result is a robots.txt that blocks all crawling: Google cannot index anything. It is the most silent error that exists because the website works perfectly for users, yet in Search Console there are no indexed pages.
It occurs more often than expected after backup restorations, staging-to-production migrations, or maintenance plugin installations that temporarily activate maintenance mode without deactivating it correctly afterwards. The check is immediate: Settings → Reading, confirm the box is unticked.
Pages WordPress generates without anyone asking for them
A standard WordPress installation generates URLs that often have no SEO value:
- Author pages (
/author/name/) — if the site has a single author, these pages show exactly the same content as the blog homepage, but at a different URL. Google interprets them as duplicate content. - Tag pages (
/tag/name/) — if tags are used with only one entry each, every tag generates a URL with a single post, which Google interprets as thin content. - Internal search results pages (
/?s=term) — every search a user runs on the site generates an indexable URL with variable, unpredictable content. - Blog pagination (
/page/2/,/page/3/…) — paginated archive pages with few entries per page multiply URLs carrying partial content.
The volume of these URLs can exceed that of real content pages on sites with many categories and tags. The standard solution is to use an SEO plugin (Yoast, Rank Math) to mark those content types as noindex, but this must be done with judgement: not everything WordPress generates should be blocked automatically. On a car rental site, for example, vehicle category pages or destination pages may have genuine SEO value if they carry sufficient editorial content.
Duplicate sitemaps and contradictory metadata
A frequent problem on installations with multiple active plugins: two or more plugins generate independent XML sitemaps. A performance plugin's XML cache may be serving a stale sitemap while the SEO plugin generates a fresh one each day. If there are discrepancies between them (URLs appearing in one but not the other, different last-modified dates), Google may not know which sitemap is the canonical one.
The same logic applies to metadata: if the active theme generates its own og:title and og:description tags in addition to the SEO plugin, the result is duplicated or contradictory metadata in the <head> of each page. Search engines typically ignore the repetitions and keep the first instance, which may not be the one configured in the SEO plugin.
Unoptimised images: the direct cause of a high LCP
WordPress does not optimise images on upload. A car photograph taken directly from a camera can weigh 6–10 MB with dimensions of 5,000 × 3,000 pixels. On mobile, that image is displayed in a column 400 pixels wide, but the browser downloads it in full before resizing it. The direct result is a high LCP and a low PageSpeed score on mobile — exactly as in the case analysed.
The three basic fixes that resolve most cases:
- Automatic compression and resizing on upload (plugins such as ShortPixel, Imagify or Smush).
- WebP or AVIF format instead of JPEG or PNG, which at equivalent visual quality weigh between 25 and 50% less.
loading="lazy"attribute on images outside the initial visible area, so they do not block the loading of the main content.
The hero or header image — the one immediately visible without scrolling — must be treated differently: it should not have lazy loading, but explicit preloading with the <link rel="preload"> tag in the <head>. This is one of the changes with the greatest direct impact on LCP.
Updates that introduce technical regressions
Every update to WordPress, a theme, or a plugin can introduce changes that affect SEO without any warning: an updated security plugin may add rules to robots.txt, an updated theme may include additional scripts that increase render-blocking time, a WooCommerce change may alter the URL structure of product pages and generate 404s on the old ones. The car rental case is an exact demonstration of this pattern.
The good practice is not to stop updating — updates are necessary for security — but to establish a verification protocol after each one: a quick PageSpeed check, a robots.txt inspection, and a pass through Search Console to detect new coverage errors before they accumulate.
How to prioritise technical findings
A technical audit can surface dozens of detected problems. Not all carry the same impact, and not all require the same remediation effort. The prioritisation framework used at Gecko Studio combines two criteria: impact on crawling and indexation (what blocks Google directly comes first) and volume of affected pages (an error affecting 481 URLs is more urgent than one affecting 2).
Applied to the case analysed, the action sequence would be:
| Priority | Problem | Impact |
|---|---|---|
| 1 — Critical | 481 crawled, not indexed (out of 750) | Nearly two thirds of the site outside the index; a compound diagnosis requiring root-cause disaggregation (duplicate canonical, thin content, contradictory signals) |
| 2 — Critical | Mobile Core Web Vitals (68/100, 3 signals failing) | Direct negative ranking signal; the historical data 98→68 proves the cause is identifiable and reversible |
| 3 — High | 28 duplicate canonicals (GSC) | Google is overriding the declared canonicals on those pages; until resolved, authority signals are not consolidating correctly |
| 4 — High | 35 avoidable 302 redirects | Potential authority loss on URLs with inbound links; technically straightforward to fix |
| 5 — Medium | 63 not found (GSC) | URLs Google knows about but that return an error; review which carry links and redirect them |
| 6 — Medium | 45 noindex (GSC) | Verify all are intentional; any accidental noindex suppresses pages that should be in the index |
| 7 — Low | 4 timeouts (crawl) and 2 404 errors | Low volume; monitor to ensure they do not grow |
The criterion that causes most confusion in practice is the 481 "crawled, not indexed" figure. Many people want to attack it directly, as though it were a number that can be reduced in one go. In reality it is a symptom with multiple causes, and when the duplicate canonical, thin content, and contradictory-signals problems are resolved, the number falls naturally. Attacking it without resolving the root causes does not work.
From technical audit to action plan in a technical SEO audit
A well-executed technical audit does not end with a findings report: it ends with an action plan ordered by impact, with a named owner for each task. The difference between an audit that moves rankings and one that ends up in a drawer is precisely that: the translation of technical data into concrete actions with a prioritisation criterion.
The technical block is the foundation of any SEO strategy. Without it in order, content work performs below its potential and external link-building does not distribute correctly across the site. That is why our methodology always resolves the technical layer first before moving on to on-page analysis or authority building.
If you want to see how this block fits within a complete SEO audit, the SEO audit guide covers all layers in sequence. If you would prefer us to review the technical layer of your site directly, at Gecko Studio we carry out technical and full SEO audits with a detailed report, real metrics scorecard, and prioritised action plan.
Frequently asked questions about technical SEO audits
What is a technical SEO audit and what does it analyse exactly?
A technical SEO audit is the systematic diagnosis of all the factors that affect how Google accesses, crawls, indexes, and processes a website. It analyses the crawling and indexation state (which pages Google can read and which it cannot), Core Web Vitals and page speed, canonical and duplicate configuration, redirects, and server errors. For single-language sites it does not include hreflang because there are no language versions to coordinate; that module applies when the site has content in more than one language, as explained in the article on international SEO audits.
How often should a technical SEO audit be carried out?
At a minimum once a year, and always after significant changes: domain or platform migration, site redesign, mass plugin updates, or changes to the URL structure. Core Web Vitals in particular should be monitored continuously because a single theme or plugin update can degrade them — the car rental site case, with a 30-point mobile drop after an update, is the exact example. For high-activity sites a quarterly technical review is advisable.
Can a website have serious technical errors and still receive traffic?
Yes, and that is the most dangerous situation. Technical errors rarely cut traffic off at once: they erode it gradually, position by position, over months. A website can work perfectly for users while Google progressively excludes pages from the index because it cannot crawl them correctly, or because Core Web Vitals are in the failing zone. By the time the problem is detected, the damage is done and recovery takes time. Preventive technical auditing exists precisely to detect that degradation before it becomes visible in business metrics.
What is crawl budget and why does it affect technical SEO?
Crawl budget is the limit of URLs that Googlebot visits on a site within a given period of time. It is not fixed: it depends on domain authority, site size, and server response speed. If there are many pages with errors (timeouts, 404s) or with irrelevant content (thin content, unresolved duplicates), Google spends that budget on URLs that add no value and may never reach the important pages. In the case analysed, the 4 crawl timeouts are a low number, but the 481 "crawled, not indexed" pages suggest that a significant portion of the budget is being spent on pages Google visits but discards.
What are the most common technical SEO problems in WordPress?
The most frequent ones we diagnose are: the "discourage search engine indexing" checkbox active under Settings → Reading (blocks all crawling), theme changes that introduce Core Web Vitals regressions, unoptimised images that push LCP up on mobile, indexable author and tag pages with duplicate or thin content, XML sitemaps generated by two different plugins with contradictory content, and conflicts between caching plugins and SEO plugins that serve stale metadata. Most have a known fix with proper SEO plugin configuration and a post-update verification protocol.
What is the difference between a technical SEO audit and a full SEO audit?
The technical audit covers exclusively the infrastructure layer: how Google accesses and processes the site. A full SEO audit additionally includes on-page analysis (titles, meta tags, content structure), keyword and search intent analysis, external link profile review, and competitor analysis. The technical layer is the first block reviewed in any audit because it conditions the performance of everything else: if there are unresolved crawling, speed, or canonical problems, work on the upper layers performs below its potential.