# Technical SEO audit: what it checks, step by step, and what you get at the end > What a technical SEO audit checks: indexing, canonicals, redirects, Core Web Vitals, schema, hreflang and internal links. With real examples, step by step. URL: https://thenichesociety.ro/en/blog-audit-tehnic-seo-ce-verifica A technical SEO audit checks whether Google can find, read and correctly understand your pages, before anyone talks about content or links. **It looks at indexing, canonicals and redirects, speed and Core Web Vitals, structured data, language versions and internal links.** At the end you get a list of problems ranked by impact, each with its evidence and its fix, not a colourful score. ## What a technical SEO audit is and how it differs from the rest A technical SEO audit answers a simple question: can Google reach your pages, read them and understand which of them matter? It does not judge whether the copy is good or whether you have enough links from other sites. It looks at the foundation. If the foundation is crooked, everything you build on top of it works at a loss. And unlike content, technical problems usually hit dozens of pages at once, not a single one. The difference from a content audit is easy to explain. A content audit asks whether the page answers what people are searching for. A technical audit asks whether the page even reaches Google in the right form. In practice, the technical audit is the first step of any [SEO optimisation](https://thenichesociety.ro/en/seo-services) project, because it tells you what needs fixing before you invest in new articles. Below we go through the checks one by one, in the order we run them. For each one we add a real example, found on our own website. Not because we enjoy showing our mistakes, but because they are exactly the kind of problems you cannot see with the naked eye and that a good audit catches. All of them have been fixed, and we briefly describe each fix along the way. ## Step 1: indexing and crawler access The first thing we check is whether the important pages are in Google's index. The reliable source here is the Page indexing report in Search Console, not a site: search on Google. The report shows which pages are indexed and, for the rest, the reason: a 404 error, a page marked noindex, blocked by robots.txt, a duplicate without a user-selected canonical, or "crawled, currently not indexed". Google states clearly in its documentation that you should not expect every URL on your site to be indexed, only the canonical pages. So don't panic at a list of unindexed pages. Look at whether any page that brings in money is on it. That is where the work begins. If your main service page shows up as "crawled, currently not indexed", that is a problem. If filter pages or URLs with parameters show up, that is often exactly the behaviour you want. Our example: on 16 September 2026, Search Console emailed us a "Not found (404)" error for an address of the form /blog/cat-costa-un-site-de-prezentare. That page did not exist and was not linked from anywhere in the menu or the text. The cause was in the structured data: every article declared a /blog/article-name address in its breadcrumb schema, when the articles actually live at /blog-article-name. Google also follows the addresses in the schema, not just the visible links. We corrected the address in the schema, added a 301 redirect for any old address of that type and extended our automated link check so it also reads the addresses inside JSON-LD. 30 minutes, free. We'll tell you honestly if it makes sense. ## Step 2: canonicals, redirects and duplicate pages Almost every site has several addresses leading to the same content: with and without www, with and without a trailing slash, with tracking parameters. Google picks one of them as the main version. Your job is to give it signals that say the same thing. Google's documentation describes a redirect as a strong signal, the canonical tag as a strong signal too, and the sitemap as a weak one. And it explicitly warns against specifying different canonical URLs for the same page through different methods. That is exactly what we had found on the old version of our website, in the audit run on 6 September 2026. Every page in the sitemap except the homepage was listed without a trailing slash. The server 301-redirected them to the version with the slash. And the page with the slash had its canonical tag pointing back to the version without it. Three signals, two directions. For Google it is like saying "go over there" and, once it arrives, "actually, go back". The fix is not complicated, but it has to be done in all three places at once: the address in the sitemap, the redirect target and the canonical must be the same URL, character for character. In the rebuilt site we tied all three to a single rule for building addresses, so they can no longer drift apart. Then we checked on the published site that every address in the sitemap answers with a 200 directly, with no redirect along the way. ## Step 3: speed and Core Web Vitals Core Web Vitals are three measurements Google uses to describe the real experience on a page. The thresholds Google recommends are: LCP, the moment the main element appears, under 2.5 seconds; INP, how quickly the page responds to a click, under 200 milliseconds; CLS, how much the content jumps while loading, under 0.1. Google says these measurements align with what its ranking systems seek to reward, along with other aspects of page experience. In an audit you don't stop at the PageSpeed score. You measure on a phone, with an empty cache and throttled speed and CPU, on several types of pages, not just the homepage. Then you look for the cause of each problem, because a score on its own fixes nothing. A site can score well on its homepage and have serious problems on articles or product pages. That is why we pick one page from each template type and measure all of them, several times, so we don't draw conclusions from a single run. Our example, from September 2026: loading was fine, but the content jumped. On the homepage we measured a CLS of 0.117, above the 0.1 limit. The cause was the cookie banner, which appeared before the fonts had loaded and then rearranged itself, pushing the text down. Web.dev lists exactly this kind of cause among the common ones: fonts that render larger or smaller than their fallback and elements added to the page ahead of existing content. We moved the banner so it appears after the fonts have loaded. Measured on the live site after publishing, CLS dropped to 0.023. ## Step 4: structured data, headings and language versions Structured data is code that tells Google explicitly what is on the page: a business, a service, an article, frequently asked questions, a navigation trail. In an audit you check three things: whether it exists, whether its type matches the page and whether the addresses inside it lead to real pages. For validation, Google recommends the Rich Results Test. On our old site, the service pages carried only a generic local business schema, with no description of the service at all, even though they were commercial pages. Heading structure belongs here too. Each page should have a single main heading, the H1, that says what the page is about. On the old site, every page had two: the real heading and another one, identical across the whole site, left over in a hidden part of the code. Visitors never saw it. The crawler did. It is not a serious mistake, but it is the kind of mixed signal that adds up with others and makes a page harder to understand. If the site has several languages, you also check hreflang, the tag that links the versions of the same page to each other. Google requires each version to list itself and all the others, and if the links are not reciprocal, they may be ignored. It also recommends an x-default version for visitors whose language matches none of them. On our five-language site we found a subtler version of the problem: the English pages had the breadcrumb in their schema pointing to the Romanian addresses. ## Step 5: internal links and the order of the checks The last part is how pages link to each other. You look for important pages that no link leads to, internal links to addresses that redirect or return an error, and pages missing from the sitemap. On the old site, the booking page was generated and had links pointing to it, but it was missing from the sitemap. A small problem, but exactly the page you want people to find. This check is best done automatically, across the whole site, not page by page, because a person gets tired after the first few dozen links. On every release we run a script that follows all internal links, including those inside the structured data, and we publish nothing if it finds a broken one. In short, the order in which we work through a technical audit looks like this: - 01Indexing: the Page indexing report in Search Console, robots.txt, sitemap, 404 and soft 404 errors. - 02Addresses: redirects, canonicals, versions with and without www or trailing slash, parameters. - 03Speed: LCP, INP and CLS measured on a phone, on several page types, with the cause of each problem. - 04Code: validated structured data, a single H1 per page, unique titles and descriptions. - 05Languages: reciprocal hreflang, x-default, correct addresses in every language. - 06Links: broken internal links, pages with no links pointing to them, important pages missing from the sitemap. ## How long it takes, what you get at the end and when it is worth it The duration depends almost entirely on the size and complexity of the site. A brochure site with a few dozen pages is checked much faster than an online shop with thousands of products, filters and URL variants. Access to Search Console matters too: without it, a good part of the checks become guesswork, because you can't see what Google sees. From the outside you can still check the addresses, the speed and the code. What you should get at the end is not a score, nor an 80-page PDF generated by a tool. It is a list of problems ranked by impact, each with three things: where it appears, the evidence, meaning a screenshot, a measurement or a line from a report, and the concrete fix. Ideally you also get a check after the fixes, because many problems look solved and are not until you see them confirmed in Search Console. A technical audit is worth doing when you have rebuilt or moved your site, when you have added a new language, when organic traffic drops without an obvious explanation or when you have good pages stuck on the second page of Google. It is not worth repeating monthly on a small site that doesn't change. There, a periodic look at Search Console is enough. ## Sources and further reading. - 01[Google Search Central — Understanding Core Web Vitals and Google search results](https://developers.google.com/search/docs/appearance/core-web-vitals) - 02[Google Search Central — How to specify a canonical URL with rel="canonical" and other methods](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls) - 03[Google Search Central — Tell Google about localized versions of your page](https://developers.google.com/search/docs/specialty/international/localized-versions) - 04[Google Search Console Help — Page indexing report](https://support.google.com/webmasters/answer/7440203) - 05[Google Search Central — Breadcrumb (BreadcrumbList) structured data](https://developers.google.com/search/docs/appearance/structured-data/breadcrumb) - 06[web.dev — Cumulative Layout Shift (CLS)](https://web.dev/articles/cls) 30 minutes, free. We'll tell you honestly if it makes sense. ## Frequently asked questions ### What is a technical SEO audit? It is a check of how well Google can find, read and understand the pages of a website. It looks at indexing, canonicals and redirects, speed and Core Web Vitals, structured data, language versions and internal links, not at the quality of the copy. ### How do you do a technical SEO audit yourself? Start with the Page indexing report in Search Console and look for important pages that are not indexed. Then check that the sitemap, redirects and canonicals point to the same address, measure speed on a phone, validate structured data with the Rich Results Test and look for broken internal links. ### How long does a technical SEO audit take? It depends on the size of the site. A brochure site with a few dozen pages is checked much faster than an online shop with thousands of products and filters. Access to Search Console makes the whole process shorter and more reliable. ### What do you get after a technical SEO audit? A list of problems ranked by impact, each with where it appears, the evidence and the concrete fix. A good audit also includes a check after the fixes, confirmed in Search Console. ### What is the difference between a technical SEO audit and a content audit? A technical audit checks whether pages reach Google correctly. A content audit checks whether pages answer what people are searching for. The technical one usually comes first, so you don't invest in content on a foundation that doesn't work. ### Let's see what can be automated in your business. A free 30-minute session: we'll tell you what can be automated, how long it takes and what it costs, with a fixed price after discovery. We reply the same business day.