Technical SEO audit

Technical SEO is the layer that decides whether Google can reach your content, understand what it’s about and add it to the index. It isn’t about keywords or producing more text. It’s about removing the obstacles that keep good content from showing up.

It’s also the part with the best return per hour of work, because it’s the only one where the gain comes from fixing errors, not from competing with someone.

The errors we see most

Soft 404s

The site redirects every nonexistent URL to a “not found” page that returns a 200 status. To Google, that means every wrong address is a valid page. It logs the redirects, spends crawl budget and starts to distrust the site’s structure.

The fix is trivial and almost nobody does it: the error page has to return a real 404 (in Portuguese).

Canonicals pointing to the wrong place

Pages with a canonical pointing to the homepage or to a paginated version, or no canonical at all on a site that serves the same URL with and without a trailing slash. The result is Google choosing on its own which version to index, and it doesn’t choose the one you wanted.

Duplicate or conflicting structured data

Two plugins outputting Organization with different identifiers, or FAQPage marking up questions that aren’t visible on the page. Bad markup isn’t neutral: it can cost you rich results in search.

Robots.txt blocking what it shouldn’t

A Disallow carried over from the staging environment, or a block on the folder that serves CSS and JavaScript. In the second case, Google can’t render the page and ends up evaluating something that isn’t what the user sees.

Core Web Vitals outside the thresholds

LCP above 2.5 s, CLS above 0.1 or INP above 200 ms (linked guides are in Portuguese). What counts is field data from real users, not a lab tool’s score.

No internal linking architecture

A site with a hundred articles where none links to another, and none links to the page that sells. The content builds authority and it goes nowhere.

What the audit covers

• Crawling and indexing: Search Console coverage, crawl logs, crawl budget (in Portuguese), orphan pages, indexed pages that shouldn’t be.
• Architecture: URL structure, click depth, topic silos (in Portuguese), internal link distribution.
• Duplication: canonicals, URL parameters, pagination, www vs. non-www, HTTP vs. HTTPS.
• Structured data: validation, conflicts between generators, rich result opportunities.
• Performance: Core Web Vitals in the field and in the lab, critical rendering path, font loading, images, third-party JavaScript.
• HTTP status: redirect chains, loops, 404s from internal links, soft 404s.
• Rendering: what the crawler sees compared to what the user sees.
• Internationalization, when there’s more than one language: hreflang and reciprocal pairs.

What you get

Not a tool-generated, two-hundred-page PDF. A prioritized plan, with each item stating three things: what the problem is, what the estimated impact is and what it costs to fix.

It’s ordered by impact divided by effort, because the question you’ll ask is “what do I do first?” If your team will do the work, the plan is written for developers, with code examples. If you prefer, we do it.

Timeline, and why nobody can guarantee rankings

Indexing and HTTP status fixes show up in days or weeks: it’s Google re-evaluating something that was blocked. Ranking gains for competitive terms take months, and depend on content and authority, not just technical work.

On guarantees, let’s be direct: Google doesn’t sell or guarantee organic rankings. Anyone promising the top spot in thirty days is selling luck, or will target terms nobody searches for so they can show you a chart going up.

What you’re hiring is the removal of technical obstacles and the building of relevance. Rankings are the result.