What is technical SEO?
Technical SEO means getting a site’s structure, speed and indexability in order. It answers three questions:
- Does Google find your pages? Crawling, robots.txt, the sitemap and internal links.
- Does Google understand your pages? Rendering, canonical tags and structured data.
- Does the page work for visitors? Speed, mobile and HTTPS.
Technical SEO is not writing content or earning links. It is the foundation that the rest of search engine optimization is built on.
Technical SEO matters most in three situations: the site is not indexed, a page is so slow that visitors leave before the content appears, or Google crawls the wrong pages and skips the important ones.
The main areas of technical SEO
Fix what blocks indexing or breaks the page first. Fine-tune the details only after that. The table shows what a healthy area looks like and how to recognize a problem.
| Area | Good sign | Warning sign |
|---|---|---|
| Crawling and indexing | Important pages are in the index according to Search Console | The sitemap lists pages that Google does not index |
| Sitemap | Lists only published, indexable pages | Contains 404 pages, redirects or noindex pages |
| Robots.txt | Does not block CSS, JavaScript, image or content paths | An important folder is blocked by accident |
| Canonical and duplicates | Every page has a correct, self-referencing canonical | The canonical points to the wrong page or to a noindex page |
| Speed | LCP under 2.5 s and CLS under 0.1 on mobile | The main image, fonts or scripts delay loading |
| Structured data | Valid JSON-LD that describes the visible content | Errors in the Rich Results Test, or types that do not match the page |
| Internal links | Every important page is reachable in 1 to 3 clicks | Important pages are not linked from anywhere |
| Rendering | Content is ready in the HTML | Content appears only in the browser through JavaScript |
Crawling and indexing
Crawling is the starting point of technical SEO: if Google cannot find your pages, it cannot index them.
Google’s crawler (Googlebot) moves through your site by following links from one page to the next. It does not find every page automatically. Your job is to make sure Googlebot finds the right pages and leaves the useless ones alone.
robots.txtSitemapInternal linksCanonicalIndex - robots.txt
- Sitemap
- Internal links
- Canonical
- Index
Crawling and indexing are two separate steps. When crawling, Googlebot fetches the page. When indexing, Google evaluates it and decides whether to add it to the search index. Crawling is usually blocked by robots.txt, a server error or the fact that no link leads to the page. Indexing is blocked by a noindex tag, a canonical that points to another URL, thin content or a duplicate.
Robots.txt
Robots.txt is a text file in the root of the site. It tells search engines which paths they may crawl. It is not protection: Google can still index a blocked URL if other sites link to it.
The most common mistake is blocking CSS or JavaScript files. Google then cannot render the page correctly. Use the URL Inspection tool in Search Console to check that Google sees the page the same way a visitor does.
Excerpt from this site's robots.txt All search engines and AI crawlers allowed, sitemap URL included.
User-agent: *
Allow: /
Content-Signal: search=yes, ai-input=yes, ai-train=yes
User-agent: GPTBot
Allow: /
User-agent: OAI-SearchBot
Allow: /
User-agent: ClaudeBot
Allow: /
User-agent: PerplexityBot
Allow: /
Sitemap: https://jondillemuth.fi/sitemap.xmlAI crawlers are allowed separately, because some CDN services block them by default. A separate Allow makes the decision visible. The full file also lists Google-Extended, Applebot-Extended and CCBot, among others.
XML sitemap
The sitemap lists the pages you want Google to index. It does not guarantee indexing, but it helps new pages get found faster. Check the sitemap at the start of every audit:
- The sitemap opens without errors, and robots.txt points to the right URL.
- Every URL returns a 200 response. It contains no noindex pages, redirects or pages overridden by a canonical.
lastmodchanges only when the content really changes.- The sitemap has been submitted to Search Console, and Google has read it recently.
Bing and Yandex also support the IndexNow API, which reports a new or changed page right away. Google does not support IndexNow, but in Bing it speeds up indexing noticeably.
Indexing issues
The Pages report in Search Console shows which pages are in the index and why the rest are not. Screaming Frog shows you the same picture from your own crawl of the site.
| Why a page is not indexed | Fix |
|---|---|
| Noindex tag | Remove the meta robots noindex if the page should appear in search |
| Canonical points to another page | Make the canonical point to the page itself |
| Soft 404 | The page returns 200 but the content is empty: add content or return a 404 |
| Server error | Investigate 5xx responses and timeouts in the server logs |
| Thin content | Write real content for the page or merge it with another page |
The fastest check is a Google search for site:domain.com/page/. If the page does not appear, it is not in the index. If the sitemap lists 100 pages and the index holds 30, start with the largest exclusion reason in Search Console.
Canonical tags
A canonical tag tells Google which URL is the primary version of a page. The same content can be available at many URLs: with and without a trailing slash, over http:// and https://, with and without www, and with tracking parameters (?utm_source=linkedin). Without a canonical, the value of links can be split between these versions.
Best practice is a self-referencing canonical on every page, even when there are no duplicates:
<link rel="canonical" href="https://domain.com/blog/article/" />Common mistakes:
- The canonical points to a noindex page. Google gets a contradictory signal.
- The canonical points to different content. Google may ignore it completely.
- The canonical is missing. Google guesses which version is primary.
- A relative URL (
href="/"). It works, but an absolute URL is safer.
URL structure
A good URL tells both Google and the visitor what the page is about before it is opened.
| Check | Good implementation | Risk |
|---|---|---|
| Length and clarity | /services/seo-consulting/ | /p/12345/ or a path with a date and filler words |
| Characters | Lowercase a to z, numbers and hyphens | Accented letters, capitals, underscores or special characters |
| Hierarchy | Important pages at most three levels deep | /category/subcategory/sub-subcategory/page/ |
| Parameters | Content at its own URL | ?ref=email&session=abc123 creates new URLs for the same content |
| Stability | The URL does not change when the title gets a small update | A year or campaign name forces a redirect later |
Title tags, meta descriptions and search result appearance
Titles and meta descriptions are also a technical check: does the site produce its own title and description for every indexable page? Google may rewrite the description, but your own description gives it a starting point.
| Element | Check | Fix |
|---|---|---|
| Title | Every indexable page has its own title | Create a title template and find duplicates with Screaming Frog |
| H1 | The page has one main heading that matches its topic | Do not put extra H1 headings inside components |
| Meta description | The description is page specific and matches the search intent | Write them by hand for service and article pages |
| Search result | The title is not cut badly, and the description promises the right thing | Test the most important pages with a search result preview |
Do not optimize a title separately from the content. If the title promises a checklist, the page needs a checklist. Otherwise the click-through rate may rise for a while, but visitors leave quickly.
Duplicate content
Duplicate content means the same or nearly the same content is available at several URLs. It is rarely copying: most often the site’s own technology creates the duplicates. As a result, link value is split, crawling is spent on the same content and Google may show the wrong version in search.
| Where the duplicate comes from | Fix |
|---|---|
| www and non-www | 301 redirect to one version |
| http and https | 301 from all http traffic to https |
| Trailing slash and no trailing slash | Choose one format and redirect the other to it |
| URL parameters (sorting, tracking) | Canonical to the version without parameters |
| Same product in several categories | Canonical to the main version, or a product URL that does not depend on the category |
Online store filters and variants create the most duplicates. They are covered in the ecommerce SEO guide.
Thin content
Thin content means pages with so little text that Google does not consider them worth indexing. The fix depends on the page type:
| Page type | Fix |
|---|---|
| Listing page (blog index, category) | A short introduction: which topics the section covers and for whom |
| Useless page (archive, tag, parameter page) | Noindex or removal |
| Valuable but thin page (service, product) | Add content: what the service includes, who it suits, what results to expect |
| Generated page (filter variant) | Canonical to the main version or noindex |
Duplicates and thin content on this site Screaming Frog, October 12, 2026: no duplicates, three thin listing pages.
The Screaming Frog crawl on October 12, 2026 found 0 exact and 0 near duplicates across 46 HTML pages. All 46 pages have a self-referencing canonical. Three settings are enough for this: a trailing slash at the end of every URL, an automatic canonical on every page and https only (http redirects with a 301).
Three pages are thin, and all of them are listing pages: the Finnish case studies page (99 words), the audits page (162 words) and the English case studies page (129 words). The fix is the first row of the table: a short introduction that says what the section contains and who it is for.
How do Core Web Vitals affect rankings?
Core Web Vitals is Google’s set of three metrics that measures user experience: loading speed (LCP), responsiveness (INP) and visual stability (CLS). Google uses field data from real users (CrUX) in rankings, so a poor result can lower rankings. The lab score in PageSpeed Insights is a development aid.
LCP is most often the metric that decides. Fix the largest bottleneck first: if the LCP element is an 800 KB image, cleaning up JavaScript will not help, and if the server responds slowly, compressing images will not remove the delay.
| LCP problem | Fix |
|---|---|
| Large images | WebP or AVIF, srcset for different screens, lazy loading for everything except the main image |
| Slow server (TTFB) | CDN, static generation, edge caching |
| Render-blocking CSS or JavaScript | Critical CSS inside the page, JavaScript with the defer attribute |
| Web fonts | font-display: optional or swap, plus preload |
| Third-party scripts | Tag manager, analytics and ads loaded asynchronously |
INP replaced FID in March 2024, and it is mainly a problem on sites with heavy JavaScript that runs in the browser (Google’s INP documentation). CLS is fixed by giving every image dimensions (width and height or aspect-ratio) and reserving space for content that loads later.
Example: this site from 93 to 100
This site is built with Astro as static HTML without a framework that runs in the browser. After launch, the homepage scored 93 on mobile. Four small fixes took it to 100:
Homepage after launch
93 / 100
Homepage, Oct 12, 2026, the better option
100 / 100
What it took to go from 93 to 100 Font loading strategy, inline CSS, prefetching and image priority.
- Font loading strategy.
font-display: swapchanged tooptional, and the font got apreload. The text no longer jumps while loading, and LCP improved. - Inline CSS. All styles are written into the HTML (
inlineStylesheets: "always"), so the last render-blocking file is gone. - Speculation Rules. The next page is prefetched in the background before the visitor clicks.
- Image priority. The main image has
fetchpriority="high", others haveloading="lazy", and every image has a srcset with three widths.
Each change raised the score by 1 to 3 points. In addition, the fallback font is adjusted to the same size with size-adjust, so the font swap does not shift parts of the page.
Image optimization in technical SEO
Images are often the easiest technical win: they affect loading speed, LCP, accessibility and image search. The goal is not to compress everything as small as possible, but to give the browser an image of the right size in the right format.
| Check | Good implementation | Why |
|---|---|---|
| Format | AVIF or WebP | Smaller file without visible loss of quality |
| Dimensions | width and height, or CSS aspect-ratio | Prevents CLS jumps while loading |
| Responsiveness | srcset and sizes | Mobile does not load a desktop-sized image |
| Lazy loading | loading="lazy" for images that are not visible right away | The first view loads faster |
| Main image | fetchpriority="high" and no lazy loading | The largest visible element loads first |
| Alt text | Describes the content and purpose of the image | Accessibility and image search |
The most common mistake is adding loading="lazy" to the main image as well. The browser then gets permission to load the image too late, and LCP slows down. In alt text, an accurate description is enough: “Screaming Frog crawl showing response codes” helps, a list of keywords does not.
Mobile-first indexing
Google evaluates pages based on their mobile version (Google’s mobile-first documentation). If the mobile version lacks content that appears on desktop (tables, FAQ or internal links hidden with CSS), Google does not see it. A slow mobile page also weakens rankings in desktop search.
A responsive site (the same HTML, with CSS adapting the view) is the recommended solution. A separate m. site needs canonical and hreflang settings and is prone to errors. On mobile, check at least these:
- Buttons and links are at least 48 × 48 pixels and far enough apart.
- Text is readable without zooming (at least 16 px).
- The page does not scroll horizontally.
- A full-screen popup does not block the content right after loading. Small banners and cookie notices are allowed.
HTTPS and security headers
HTTPS is a basic requirement, not a competitive advantage. It has been a Google ranking signal since 2014, and without it browsers warn visitors. The baseline is a certificate (Let’s Encrypt is free), a 301 redirect from http to https, HSTS and a page that loads no resources over http (mixed content).
On this site, Screaming Frog on October 12, 2026: every page on https, 0 mixed content warnings and HSTS on every page.
Security headers and email authentication They do not raise rankings directly, but they strengthen trust.
| Header | What it does |
|---|---|
| Strict-Transport-Security | Forces the browser to use https (includeSubDomains and preload recommended) |
| Content-Security-Policy | Limits where the page can load resources from and prevents XSS attacks |
| X-Content-Type-Options: nosniff | Stops the browser from guessing the file type |
| X-Frame-Options: SAMEORIGIN | Prevents the page from being embedded in another site’s iframe |
| Referrer-Policy | Defines what information is passed on when a visitor clicks a link |
SPF, DKIM and DMARC are not technical SEO, but if your domain sends offers or newsletters, they have to be in place. Otherwise messages end up in spam and the domain’s reputation suffers.
What does structured data mean in technical SEO?
Structured data (Schema Markup) is JSON-LD markup that tells Google what a page is: an article, a business, a service or a person. It does not raise rankings directly, but it enables rich results, such as breadcrumbs and business details, and it helps AI search identify entities too. Google recommends Organization and WebSite data for the homepage, not for every page.
| Type | Use | Rich result |
|---|---|---|
| Organization | Homepage: name, logo, contact details | Knowledge panel |
| LocalBusiness | Local business: address, opening hours, service area | Maps and local search |
| Article / BlogPosting | Articles: author, publication date, image | Article details |
| BreadcrumbList | Navigation path | Breadcrumb in the search result |
| Service | Service pages: service type and area | Service details |
| FAQPage, HowTo | FAQ and instructions | No longer for ordinary sites (FAQ only for government and health sites since August 2023) |
Add structured data as JSON-LD and always validate it with the Rich Results Test or the Schema Markup Validator.
Structured data is best kept in one place. On this site, the business, the person and the local business are defined once on the homepage with an @id, and articles refer to them. How that speeds up fixes is shown in example 1.
Site architecture and internal linking
Site architecture describes how pages are organized and how they link to each other. A good structure helps visitors find what they are looking for and helps Googlebot crawl efficiently. Three metrics are enough: click depth, pages without internal links and anchor texts.
Click depth (crawl depth) is the number of clicks needed to reach a page from the homepage. Important pages should be at most three clicks away. On this site (Screaming Frog, October 12, 2026), the homepage is at level 0, 17 pages at level 1, 26 pages at level 2 and one page at level 3.
Internal links share value between pages. At least one link must lead to every page, the anchor text must say what the target is about (“read the technical SEO checklist”, not “click here”) and an article should link to articles on the same topic and to the service page.
Breadcrumbs (Home › Blog › Technical SEO) show visitors where they are and show Google the hierarchy. Add them as HTML at the top of the page and as BreadcrumbList structured data.
The most effective way to organize content is the pillar-cluster model: a pillar page covers a broad topic, cluster pages go deeper into its areas and all of them lead to the service page. The model is illustrated in the small business SEO guide.
How does JavaScript rendering affect indexing?
Google sees static HTML right away. Content created with JavaScript in the browser goes into a separate rendering queue, and it may appear in search days or weeks later. This is the biggest technical SEO risk in React, Vue and Angular applications, which render in the browser by default.
| Rendering method | What happens | From Google's point of view | Examples |
|---|---|---|---|
| CSR (in the browser) | The server sends an empty page and JavaScript, the browser builds the content | Content appears only after rendering, with a delay | React, Vue and Angular apps by default |
| SSR (on the server) | The server produces finished HTML for every request | Content is visible right away | Next.js, Nuxt |
| SSG (at build time) | HTML is produced in advance at publication | Content is visible right away, and the page is the fastest | Astro, Hugo, Next.js static export |
The delay is critical for time-sensitive content: campaign pages, new products and changing prices. If search shows an old price for weeks, the cause is often the rendering queue.
Check rendering like this:
- Open the page source. Press Ctrl+U (Cmd+Option+U on a Mac). If important text is missing and you only see scripts, the page is rendered in the browser.
- Test without JavaScript. Turn JavaScript off in Chrome’s developer tools and reload the page. Whatever disappears, Google does not see before rendering.
- Look at Google’s view. The URL Inspection tool in Search Console shows the tested page’s HTML after rendering. Compare it with what the browser shows.
- Crawl in JavaScript mode. Screaming Frog can render pages and reports on which pages content or links appear only through JavaScript.
On this site, Astro produces all content as HTML at build time. Screaming Frog found content created by JavaScript on three pages, and it is the booking component, not text meant for search.
Technical SEO and AI search
AI search (Google’s AI Overviews, ChatGPT, Perplexity) uses the same foundation as traditional search. If the site cannot be crawled, AI cannot cite it. These systems favor clearly structured content (definitions, tables, lists) and trustworthy sources. Once the technical foundation is in place, the next step is AI search optimization.
Robots.txt is where you decide how AI crawlers may access the site:
| Crawler | Company | Purpose |
|---|---|---|
| GPTBot | OpenAI | ChatGPT and model training |
| OAI-SearchBot | OpenAI | ChatGPT search |
| ClaudeBot | Anthropic | Claude and model training |
| PerplexityBot | Perplexity | AI search |
| Google-Extended | Gemini training (does not affect Google Search) |
If you want to appear in AI search, do not block these. If you only want to block training use, block Google-Extended and allow the search crawlers.
llms.txt is an optional file that describes the site’s content for language models. This site uses one, but so far there is no evidence that it improves visibility. A good addition, not a priority.
Invented URLs are a new phenomenon: AI may refer to a URL that does not exist, for example /en/blog/technical-seo-guide/. Watch the 404 report, and if such a URL gets traffic, redirect it with a 301 to the right page.
Hreflang and multilingual sites
If a site has several language versions, hreflang tags tell Google which page is in which language and which pages are translations of each other. Without them, Google may show the searcher the wrong language version.
<link rel="alternate" hreflang="fi" href="https://domain.com/sivu/" />
<link rel="alternate" hreflang="en" href="https://domain.com/en/page/" />
<link rel="alternate" hreflang="x-default" href="https://domain.com/sivu/" />Every language version must refer to the other and to itself, and x-default tells which version is shown to everyone else. This site is in Finnish and English (17 English pages). Screaming Frog on October 12, 2026: hreflang on all 46 pages. The only note concerns the privacy policy: it is noindex on purpose, so its language pair points to a page that is not indexed.
Redirects
Redirects are needed when a URL changes, a page is removed or content is merged. Done correctly, they do no harm.
| Type | When and how |
|---|---|
| 301 (permanent) | The content has moved permanently. Passes link value to the new URL. |
| 302 (temporary) | The content is elsewhere for a while. Not suitable for permanent changes. |
| Chain (A → B → C) | Every hop slows things down and uses crawling. Shorten it to A → C. |
| Loop (A → B → A) | Google stops crawling, and the page is not indexed. Fix it right away. |
Check the situation in Screaming Frog: Response Codes › Internal Redirection (3xx). One or two internal redirects are normal. Ten or more means URL changes have not been planned. On this site, there were zero internal 3xx responses on October 12, 2026: links point straight to the final URL.
Crawl budget: when does it matter?
Crawl budget is the number of pages Googlebot crawls on your site in a given time. It becomes a real limit only on sites with more than 10,000 pages, or when most URLs are parameters, filter variants or thin pages. A slow server and redirect chains also use it up.
On a small business site with 30 to 200 pages, crawl budget limits nothing. This site’s 46 HTML pages were crawled with Screaming Frog in under two minutes. Focus on content and links instead. Follow the situation in the Crawl stats report in Search Console: does Google crawl regularly, is the response time rising and is the number of “Crawled - currently not indexed” pages growing?
Broken pages and links
Every broken link sends the visitor to an error page and wastes the value of the link. They appear when pages are removed, URLs change or external sites remove their pages. You find them in the Pages report in Search Console (“Not found (404)”), in Screaming Frog (Response Codes › Internal Client Error (4xx) and Inlinks) and in the broken link report of backlink tools.
| Situation | Fix |
|---|---|
| The page has moved to a new URL | 301 from the old to the new URL, and internal links straight to the new one |
| The page was removed, the content is elsewhere | 301 to the closest matching page |
| The page was removed, there is no replacement | 410 (Gone) and internal links removed |
| An external link points to an old URL | 301, and ask the linking site to update the link |
On this site on October 12, 2026: 0 internal 4xx errors and 4 broken external links to third-party pages. Internal ones are always fixed first, because they are under your own control.
Measuring technical SEO
Technical SEO without measurement is guesswork. Without a baseline, you do not know whether a change improved something or broke something.
| Metric | Tool | What to watch |
|---|---|---|
| Indexed pages | Search Console, Pages | Is the index growing, and which reasons exclude pages? |
| Crawling | Search Console, Crawl stats | Does Google crawl regularly, and has the response time risen? |
| Core Web Vitals (field) | Search Console, CrUX | Do LCP, INP and CLS stay in the good range? |
| Organic traffic and conversions | GA4 | Does the fix show up in traffic and contact requests? |
| 404 errors | Search Console, Screaming Frog | Does the number of errors fall after the fixes? |
| Structured data | Search Console, Enhancements | Does the structured data work without errors? |
- Baseline
- One change
- Wait 2–4 weeks
- Compare
- Into revenue
- Record the baseline. Save the Pages report and Core Web Vitals in Search Console before the change.
- Make one change at a time. If you change everything at once, you do not know what had the effect.
- Wait 2 to 4 weeks. Crawling, indexing and re-evaluation take time.
- Compare the same metrics over the same period. In Search Console, compare three months with the previous three.
- Connect the result to revenue. A technical fix shows first in the index, then in organic traffic and finally in contact requests or sales.
Technical SEO is not a one-time project. Pages are added to the site, old ones are removed and updates break things.
Practical examples: technical SEO in action
Two cases show what a technical fix looks like before and after.
Example 1: fixing structured data in three days
The Screaming Frog crawl of this site on April 16, 2026 reported 20 rich result warnings on 28 pages. The author field of the articles was a plain string, and the LocalBusiness data was missing coordinates on five service pages.
April 16, 2026
20 warnings
April 19, 2026, the better option
@id reference, coordinates and opening hours added. One change to the layout file fixed every article, because the structured data is kept in one place.1 warning
If every page had carried its own copy of the structured data, the same fix would have needed 28 separate edits. A central structure turns the fix into a single change.
Example 2: robots.txt blocked the images (client case)
Traffic to a WordPress site fell by 40% in a month. Search Console showed the status “Blocked by robots.txt” for eight pages.
After the mistake
Disallow: /wp-content/uploads/ to robots.txt to save crawling. Google could not render the pages correctly, because the images did not load.−40%
Three weeks later, the better option
Recovered
The lesson: do not use robots.txt to block resources Google needs to render the page. If your site runs on WordPress, the WordPress SEO guide covers the platform’s own checks.
Technical SEO checklist
These ten items cover the most critical points. Tick the ones that are in order: the list remembers your choices on this device.
Check your own site
0 / 10 done
Want me to check the rest for you? Book a free consultation.
Monthly and quarterly checks The rest: metadata, images, security, hreflang and AI crawlers.
Every month:
- Every page has a title, an H1 and a meta description.
- Images have alt text and a width and height.
- There are no duplicates (Screaming Frog › Content › Duplicates).
- There are no mixed content warnings.
- There are no full-screen popups on mobile.
Every quarter:
- Security headers (HSTS, CSP, X-Content-Type-Options) are in place.
- SPF and DMARC are in the DNS records.
- At least one internal link leads to every page, and important pages are at most three clicks away.
- Hreflang is correct if the site is multilingual.
- Breadcrumbs and BreadcrumbList validate.
- AI crawler access is a conscious decision in robots.txt and in the CDN.
- The 404 report has been checked for URLs invented by AI.
Tools
| Tool | What it does | Price |
|---|---|---|
| Google Search Console | Indexing, search queries, Core Web Vitals field data, URL Inspection | Free |
| PageSpeed Insights | Core Web Vitals measurement and suggested fixes | Free |
| Screaming Frog | Crawling: links, canonicals, structured data, response codes, rendering | Free up to 500 URLs, wider license for an annual fee |
| Rich Results Test | Structured data validation and preview | Free |
| Chrome DevTools | Lighthouse, network traffic, JavaScript checks | Free |
| Ahrefs or Semrush | Automated audit, backlinks, competitors | Monthly fee |
Search Console is mandatory, because it is the only source of Google’s own indexing data. Screaming Frog finds broken links, duplicates, missing canonicals and structured data errors in a single crawl. Paid tools are worth adding only when you need backlink data or competitor analysis.
When should you buy technical SEO as a service?
You can do the basic checks yourself. Technical SEO is worth buying as a service when the problem already shows in revenue or the risk is too high to guess:
- Organic traffic has fallen, and the content does not explain why.
- The site has just been redesigned, moved to a new platform or its URLs have changed.
- Search Console shows many indexing, canonical or 404 issues.
- The site is slow on mobile, and the developers do not know the root cause.
- Online store filters and variants create thousands of URLs.
- The site is built as a JavaScript application, and pages are indexed slowly.
A good technical audit is not a list of a hundred separate errors. It tells you what blocks visibility, what weakens conversion and in which order the fixes should be done.