We start every marketing engagement with a technical SEO audit because marketing sends traffic to a website, and if that website is technically broken, part of the budget leaks away before it can do anything. If Google isn't indexing your key pages, if they load slowly on mobile, or if AI search crawlers are locked out, neither ads nor content will deliver what they could. The audit shows what is blocking growth and gives you an order of work: what to fix before you spend money on traffic.
You can launch a campaign any time. But if you find out two months in that some of your landing pages aren't in Google's index, every number you collected along the way is misleading. AI search has only raised the stakes. Google's official guidance says a page can only appear as a supporting link in AI Overviews or AI Mode if it is indexed and eligible to be shown with a snippet. There are no additional technical requirements, so if you slip on the basics, you're out of the AI answers too.
- For us, the audit is step one of every marketing engagement: fix the bucket before you pour.
- We work in six steps: goals and access, crawling, indexing, rendering and speed, AI accessibility, a prioritised fix list.
- According to Google, AI features have no extra technical requirements, which makes technical SEO the foundation of AI visibility as well.
- The most common problems are boring: floods of filter URLs, robots.txt and noindex cancelling each other out, empty initial HTML, redirects forgotten after a relaunch.
- Small sites don't need a big audit. Google itself says that under 500 pages you probably don't need the indexing report.
Why don't we start with the campaign?
Because marketing is a multiplier, not a foundation: it amplifies whatever is on the site, including the bugs. We stick to this order for three reasons:
- Visibility: a page that isn't indexed can't rank, and it can't be a source in Google's AI features either.
- Measurement: if we don't know the starting point, we can't say what the campaign achieved. Google says traffic from AI Overviews and AI Mode is reported in the Search Console Performance report under the "Web" search type, not separately. So the audit doubles as a baseline.
- Paid traffic: visitors from ads land on the same pages. If those pages are slow or fall apart on mobile, you lose people there too, except you've paid for every click.
We covered the underlying principles in an earlier article. In practice, our process has six steps.
What does our technical audit look like, step by step?
1. Goals and access
We don't start with a crawler. We start with a question: which 10–20 pages actually make money? We ask for access to Search Console and analytics, because an external tool only sees the site from the outside, while Search Console shows Google's own data.
2. Crawling
We crawl the site the way a search bot would. What we look at:
- status codes: 404s, 5xx server errors, redirect chains;
- canonical tags: whether they self-reference, and whether any point to redirected or broken URLs;
- noindex and robots.txt: whether an important page has been excluded by accident;
- internal links: whether every key page is reachable in a few clicks, and whether there are orphan pages nothing links to;
- sitemap: whether it lists only live URLs that should be indexed.
On canonicals, it helps to know that Google's documentation treats redirects and rel="canonical" as strong signals, while sitemap inclusion is only a weak one. When they contradict each other, your preferred URL may not win.
3. Indexing: what does Google actually see?
The crawl shows what could be indexed; Search Console shows what was. In the Page indexing report we check whether the key pages are in, and if not, why. Google itself notes that most sites have a few unindexed pages, and duplicate URLs shouldn't be indexed anyway. What matters is whether the pages that make money are in. For individual pages, we use the URL Inspection tool.
4. Rendering and speed
If the site is built on a JavaScript framework, we compare what's in the raw HTML with what only appears after rendering. Google's JavaScript SEO guide explains that Googlebot works in three phases (crawling, rendering, indexing), and that with the so-called app shell model the initial HTML doesn't contain the actual content. Google then has to execute the JavaScript to see it.
For speed, we measure Core Web Vitals against the web.dev thresholds: LCP within 2.5 seconds, INP of 200 milliseconds or less, CLS of 0.1 or less. The recommendation is to look at the 75th percentile of page loads, split by mobile and desktop. That's why we look at real-user data where it exists, not just a lab score.
5. AI accessibility
Here we mainly check robots.txt and server-level blocking. According to OpenAI's crawler documentation, OAI-SearchBot is what surfaces sites in ChatGPT search. Opt out of it and your site won't appear in ChatGPT search answers (though it can still show up as a navigational link). GPTBot is a separate setting, so you can allow search while disallowing use of your content for model training:
User-agent: OAI-SearchBot
Allow: /
User-agent: GPTBot
Disallow: /This is an example, not a recommendation: whether to allow GPTBot is a business decision. What does happen, though, is a firewall or CDN rule quietly blocking every AI crawler without anyone knowing. We check llms.txt too, but it's not where we start.
6. A prioritised fix list
The output isn't a hefty PDF. It's a short list where every item answers three questions:
| Dimension | Question |
|---|---|
| Impact | How many money pages does it affect, and how badly? |
| Effort | A setting in an admin panel, or development work? |
| Owner | Who fixes it: us, your developer, or the platform vendor? |
High-impact, low-effort items go first. Fixing a bad robots.txt line takes minutes; a rendering problem can mean weeks of development.
What problems do we find most often?
The examples below are anonymised composites: not one client's data, but situations that keep coming up across audits, which is why we don't attach numbers to them.
The webshop whose filters generate more URLs than it has products
Colour, size, price, sort order: every combination is a new URL. Google's 2024 write-up on faceted navigation says crawling these URLs always consumes server resources and may slow down the discovery of new content. The fix is a decision about which combinations deserve their own indexable page (say, a genuinely searched "black women's running shoes") and which should stay out of the crawl. That takes knowledge of the webshop platform as well.
The company site where robots.txt and noindex cancel each other out
A few old pages were disallowed in robots.txt and, just to be safe, given a noindex tag. They stayed in the results anyway. Google's documentation is clear that noindex only works if robots.txt doesn't block the page; otherwise the crawler never sees the tag. According to Google, robots.txt simply isn't a mechanism for keeping a page out of search.
The modern site with an empty initial HTML
Client-side rendering: everything looks fine in the browser, but the raw HTML has barely any text beyond the menu. Google sees the content after rendering, but that's an extra step, and we wouldn't count on other crawlers executing JavaScript. The fix is development work: server-side rendering or pre-rendering. On a custom system, that's a job for our development team.
The migration where old URLs lead nowhere
New platform, new URL structure, no redirects from the old addresses. External links and bookmarks hit a 404. Since Google ranks redirects among the strongest canonical signals, a 301 redirect map is a mandatory part of every relaunch we do.
What happens after the audit?
Alongside the fix list, we record the baseline: indexing status of key pages, organic traffic in Search Console, Core Web Vitals and, where relevant, who the AI Overview cites for the main queries. We wrote about that kind of measurement in detail here.
Only then does the marketing start, and its order follows the audit. If category pages aren't indexed, we don't start with blog posts. If the landing page is slow on mobile, we fix that before scaling ads. If everything is fine (it happens), the audit is a short document.
That's why we like having development and marketing in one place: these considerations go in at the design stage. The G8 Alakváltók app, webshop and website were all built by us.
When don't you need a full audit?
A site with a few dozen pages doesn't need a big audit. Google's Search Console Help says outright that with fewer than 500 pages you probably don't need the Page indexing report; a few searches to confirm your key pages are findable will do. In that case we run a short check: indexing, robots.txt, mobile speed, AI crawlers. For a webshop with thousands of products, or ahead of a relaunch, we go through the whole process.
Frequently asked questions
Does a technical audit guarantee better rankings?
No. An audit finds and removes obstacles, but rankings also depend on content, competitors and the search engine itself. What it does give you: a clear view of what is holding your visibility back, and what to fix first.
Do I need a separate audit for AI search?
Not a separate one, but an extended one. Google says AI Overviews have no technical requirements beyond classic SEO. For ChatGPT search, though, it matters whether your robots.txt and server let OAI-SearchBot in, so our audit checks that too.
What do you need from me for the audit?
Search Console access (read-only is fine), analytics if you have it, the name of your platform and who develops the site. Most importantly, a list of the pages that bring in revenue.
How often should the audit be repeated?
After every major change: a relaunch, a platform switch, a new language version or a big product import. In between, keeping an eye on Search Console regularly is worth more than one big audit a year.
Curious where your site stands right now? Ask for our free SEO and AI visibility audit. If you'd like us to handle the marketing afterwards as well, you'll find the details on our marketing services page.