Donate to support freedom.
Get the same

Technical SEO Audit & Fixes

Technical SEO audit and fixes for crawl errors, index coverage, canonicals, structured data, sitemaps, metadata, internal links, and AI crawler access.

Technical SEO Audit & Fixes

A site can be well designed, quick, and still invisible. The pages exist, the copy is decent, and the enquiries do not arrive, because a canonical tag points every version of a page at a URL that returns a 404, or a template loads its body text through JavaScript the crawler never runs, or the sitemap still lists three hundred addresses from a rebuild years ago.

None of that shows up in a browser. It shows up in Search Console's coverage report, in a crawl that takes ten minutes, and in structured data test results. Our technical audit finds those problems, and the same engagement repairs them.

What technical SEO covers

Technical SEO is the part of search work that has nothing to do with writing copy. The job is to make sure a crawler can reach every page you want indexed, read it, understand what it is about, and treat the correct version as the one worth ranking. We audit against the rules this site is built on, written in our internal SEO guardrails: one canonical per indexable page, titles near sixty characters, descriptions under about 155, no accidental noindex, and a crawlable internal link into every page that should rank.

  • Crawl and index coverage: which URLs are indexed, which are excluded and why, redirect chains, soft 404s, and blocked resources.
  • Canonicals and duplicates: one canonical per indexable page, no conflicting tags, correct handling of parameters and pagination, and no staging domains competing with live pages.
  • Structured data: Organization, Service, FAQPage, Product, and BreadcrumbList markup that validates and agrees with the visible content.
  • Metadata: unique titles and descriptions inside the length limits, matched to the query each page answers.
  • Sitemap hygiene: accurate lastmod dates, no redirected URLs, the sitemap declared in robots.txt, nothing important missing.
  • JavaScript rendering: whether the main text appears in the HTML before scripts run, and whether navigation uses real anchor links a crawler can follow.
  • Internal linking: pages nothing links to, pages reachable only through a search box, and anchor text that hides the destination.
  • Speed and crawling signals where they affect indexing, handed to our performance optimization service when the underlying fix is a front-end job.
  • AI crawler access: which of GPTBot, PerplexityBot, ClaudeBot, and Google's AI surfaces may read the site, and whether an llms.txt file would help them describe the business correctly.

Who it is for

Most enquiries arrive in a few situations. A company redesigned or rebuilt last year and organic traffic never came back. A site grew page by page for a decade, and nobody can say which of its four hundred URLs are the real ones. A shop added filters and variants, and product pages began vanishing from results. A business paid for content and links for a year with no movement, because the problem sat in the template rather than the copy. A founder asked ChatGPT for a supplier in their sector, got three competitors named, and asked what could change that.

If slower pages are the problem rather than indexing, speed and performance optimization is the smaller engagement. If the structure is wrong at the content level, a CMS migration may be the honest answer before any audit.

What the audit report contains

The deliverable is a document you can act on.

  • The crawl dataset: URL counts grouped by status code, index coverage compared against Search Console, and the excluded pages with the reason attached to each.
  • A prioritised issue list: each finding with the affected URL pattern, its severity, the effort to fix it, and the outcome it blocks: indexing, ranking, click-through rate, or citation by AI systems.
  • The baseline: the queries and landing pages the site depends on today, so the effect of the fixes can be measured later instead of guessed at.
  • Template notes: which findings come from a shared component and disappear in one change, and which need separate work.
  • Evidence: the raw crawl file, screenshots of failing checks, and output from the schema validators.

What we fix

Repairs come out of the report in the order it sets. Canonical tags get corrected and conflicts removed, and noindex left over from staging gets taken out of production. Redirect chains get collapsed into single hops, with a map covering URLs that moved without one. Titles and descriptions get rewritten page by page within the length limits. JSON-LD blocks get written, validated, and wired into templates so new pages inherit them. Duplicate pages get merged or canonicalised after you approve the list. The sitemap is regenerated from live content and declared in robots.txt. Internal links get added from related pages, and orphan pages get a route in from a hub. Where rendering is the problem, content moves into the server-rendered output and navigation switches to real links.

We do the work in your CMS, theme, or repository, with each change documented in the report. If your team prefers to implement, we hand over a ticket list sized for the sprint instead.

How the engagement runs

Crawl and diagnostics come first, usually about a week: a full crawl, a comparison against Search Console and analytics, a rendering test with JavaScript disabled, and the structured data validators.

Then a short call about priorities. Revenue-related fixes come first, cosmetic warnings last, and you can reorder the list before work starts.

Implementation runs one to four weeks depending on the platform, mostly inside the codebase or CMS, so nothing waits in a queue.

Verification is the part audits often skip. We re-crawl the site, revalidate the structured data, request indexing for changed pages, resubmit the sitemap, and confirm the status codes in the redirect map. Search Console then gets watched for weeks, because a fix for one indexing problem can expose a second issue that was hidden behind it.

What it costs

Audit and fix work runs at our flat rate of $39 per hour. The audit is usually a few days of work, and a small site on a clean stack often fits inside a week. The repair phase is where scope varies: page count, how many templates the site uses, whether content needs JavaScript to appear, how much freedom the CMS gives us, and the number of languages.

We quote hourly or as a fixed scope once the crawl gives us real numbers, and you can see the report before committing to the fix list. The pricing page explains both models, the monthly capacity plans from $2,699, and the published budgets for typical orders.

Proof

design.vasilkoff.com is our own static site, built on Next.js and hosted on Vercel with no database and no plugin layer. Pages arrive as finished HTML, and metadata, structured data, and the sitemap come from the same content the visitor reads. It is the state a clean build produces, and the point we hold client sites against when a crawler sees something different.

Living Cyprus runs a React.js website beside a React Native app on a Nest.js backend, with news, events, and property listings sharing one content model. A front end like that carries several content types and a large listings dataset, so URL structure, metadata, and rendering choices have consequences. It is the class of project where an audit is worth running before the content plan.

Related services

Next step

Send the domain, plus Search Console access if you have it. We will run the crawl and tell you whether the problems are small, structural, or worth leaving alone.

Contact us with the site address and what you have noticed so far, or run the project through the Vasilkoff.info estimator to get a first scope and cost range before any conversation.