Technical SEO Audit: The Complete Process, Following One URL Through Google

I have run technical audits on sites that looked perfect and could not get a single service page indexed. I have also run them on ugly sites that ranked fine. That taught me something about how most audits are written: they list problems by category, when Google meets your site in a sequence.

I am Armen, an SEO consultant in Barcelona, and I run ACERO Digital with a team of specialists. Here is the process we follow, built around the path one URL takes through Google. Each stage can fail on its own, and the fix is different at each.

If you want the shorter checklist version, we have that separately. This is the longer one, with the reasoning behind each check.

What is a technical SEO audit?

A technical SEO audit is a review of whether search engines can discover, crawl, render and index your pages, and whether your site gives them clean signals about which version to show. It ignores what your copy says and asks only whether the machinery works.

Think of it as five gates. A URL has to be found, fetched, understood, stored and then chosen. If a page fails at gate two, no amount of work on gate five will help it.

Which gate is blocking your pages?

Start in Google Search Console, under Indexing and then Pages. This report tells you which gate each URL failed at, in Google’s own words, and it takes ten minutes.

Two statuses deserve your attention first. “Discovered, currently not indexed” means Google knows the URL exists but has not fetched it yet. “Crawled, currently not indexed” means Google fetched it and decided not to keep it.

Those are different diseases. The first is usually about crawl priority, weak internal links or a slow server. The second is usually about the page itself: thin, duplicated or too similar to another URL.

Export the list for your key commercial pages and mark each one. That single sheet will steer the rest of the audit.

Can Google find your URLs?

Discovery depends on links and sitemaps, so check both. Every page you want to rank needs at least one crawlable link from another page, written as a normal anchor with an href. A menu that only works through a click handler in JavaScript can hide a whole section from Google.

Your XML sitemap should list only the canonical, indexable, 200 status URLs you want found. A sitemap is limited to 50,000 URLs or 50 MB uncompressed, and a bloated one full of redirects and noindex pages tells Google you do not curate your own site.

Open the robots.txt file too. One stray Disallow: / left over from a staging launch has taken more sites offline in search than any algorithm update I can name. Then confirm the sitemap is declared inside it.

Can Google fetch them cleanly?

Fetching goes wrong through server errors, slow responses and redirect trouble. Crawl your site with Screaming Frog and sort by status code. Then open the Crawl stats report in Search Console, under Settings, to see how Googlebot itself experienced your server.

Here is what to look for:

• Any 5xx errors, even a few. They teach Googlebot to visit less.
• Average response time above roughly 500 milliseconds on a small site.
• Redirect chains. Google follows up to ten hops, but every hop wastes time and can dilute signals. Point old URLs straight to the final destination.
• Soft 404s, where a missing page returns a 200 status with a “not found” message.

Picture a shop in Eixample that moved to a new platform, with every old product URL redirecting through two hops. Nothing looks broken to a human. Googlebot spends its visits on the chains and reaches the new pages slowly.

Does Google see what your visitors see?

Rendering is the gate most audits skip, and it is where JavaScript sites fail. Google fetches the raw HTML first and renders the page later, so anything that only appears after scripts run arrives late, or occasionally never.

The test is simple. Open a key page in Search Console’s URL Inspection tool, run the live test and read the rendered HTML. Then compare it with the page source in your browser. If your main heading, your product description or your internal links are missing from the raw HTML and only appear after rendering, you have a dependency worth reducing.

Also check that critical resources are not blocked in robots.txt. If Google cannot load your CSS or scripts, it renders a broken version of your page.

Which version of the page does Google keep?

Duplication is the gate that catches the most small business sites. When several URLs show the same content, Google picks one and drops the rest, and it does not always pick yours.

Look for the status “Duplicate, Google chose different canonical than user” in the Pages report. It means your canonical tag said one thing and Google decided another. Usually the cause is that your own signals disagree: the canonical points one way, the sitemap lists another, and the internal links favour a third.

Make every signal point at one URL. Choose between the www and non www version, force HTTPS, and pick a trailing slash rule. Then check that parameters, such as filters and tracking codes, do not create indexable copies.

For a multilingual site, add hreflang to the check. Each language version must reference the others and itself, or Google may show the wrong one to the wrong country.

Is the site fast enough on a real phone?

Speed is a technical check, but treat it as a tiebreaker rather than a magic lever. Core Web Vitals give you three numbers: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds and Cumulative Layout Shift under 0.1.

Read the field data in Search Console’s Core Web Vitals report first, since that comes from real visitors. Use PageSpeed Insights only to find the cause once you know which page group fails.

Do not chase a perfect score. A page that passes and has thin content will still lose to a slower page that answers the question better.

What about structured data and security?

Validate structured data with the Rich Results Test and check the Enhancements section in Search Console for errors. Make sure the markup describes what is visibly on the page. For a local business, that means an accurate LocalBusiness or Organization block, and if you want the wider picture, our local SEO service covers how it ties into your Google Business Profile.

On security, confirm a valid HTTPS certificate, no mixed content warnings and no manual actions in Search Console. Those are rare, and when they appear they outrank everything else on the list.

How do you turn the findings into a fix list?

Sort every finding by two questions: does it touch a page that earns money, and how many pages does it affect? A canonical fault across all your service pages goes to the top. Missing alt text on old blog images goes to the bottom, or off the list.

Write each item so a developer can act without a meeting. Give the URL pattern, what is wrong, the evidence (a screenshot from Search Console works), the fix and how you will verify it. Then re crawl after the changes and use the Validate Fix button in Search Console.

This is the difference between an audit that gets done and a PDF that gets filed. If you want that fix list built for your own site, our SEO audit service is exactly this process, and our SEO consulting team can stay on to make sure the fixes ship.

What I would do first

Open the Pages report in Search Console today and find out which gate your best service page is stuck at. Do not start with a crawler and a 300 line report.

Once you know the gate, the fix is usually small. If you would rather not sort it out alone, get in touch and tell me the URL that should be ranking. I will tell you honestly where it is getting stuck.