Technical SEO Audit

What a technical SEO audit answers

Good content on a site Google cannot read properly does not rank. A technical SEO audit looks under the design and answers four questions, in this order.

1. Can Google reach the pages? Nothing blocks the crawler, and every page that matters is linked from somewhere.
2. Can it read them? The text, the links and the headings are in the code Google receives, not hidden behind scripts that fail.
3. Does it choose to index them? Google reaches many pages and keeps only some. I find which ones it left out, and why.
4. Are they fast enough on a phone? Measured on real mobile connections, not on office wifi.

Core Web Vitals in plain words

Core Web Vitals are three measurements Google takes of how a page feels to use.

LCP: how fast the main content appears

The time until the largest image or text block is visible. Good is 2.5 seconds or less.

INP: how fast the page reacts to a tap

The delay between a tap and the page responding. Good is 200 milliseconds or less.

CLS: how much the layout jumps

Buttons and text that move while the page loads. Good is 0.1 or less.

Lab tests and field data

A lab test is one simulated visit from one machine. Field data is what real Chrome users experienced on your site over recent weeks. Google uses the field data. I report both, and I say which is which.

Crawl and indexing: the quiet problems

Most indexing problems are invisible from the front of the site. These are the ones I check on every audit.

• robots.txt: no rule blocks pages or files that Google needs.
• XML sitemap: lists the live pages, and only those.
• Canonical tags: each page names the right address as the original.
• noindex: no tag left on a page that should appear in search.
• Redirect chains: an old address goes to the new one in one step, not four.
• Soft 404s: empty or missing pages that tell Google everything is fine.
• Duplicate URLs: the same page reachable with and without www, or with and without a trailing slash.

JavaScript rendering and heavy page builders

Some sites send Google an almost empty page and build the content afterwards with JavaScript. Google can run those scripts, but it does so later and not always completely. Text, links or prices that only exist after the script runs may be read late or missed.

I compare what the server sends with what a visitor sees. If something important appears only in the second version, it goes in the report.

Page builders cause a different problem. They are easy to edit, and they often load code for every widget on every page, used or not. That weight shows up in LCP and INP on a phone.

Bilingual checks for English and Arabic sites

A bilingual site has a set of errors of its own, and they are common in the UAE.

Hreflang tags tell Google that two pages are the same content in two languages. They only work in pairs: the English page must point to the Arabic page, and the Arabic page must point back. If one side is missing, Google ignores both. I check every pair, and the x-default tag that says which version to show when neither language matches the reader.

I also check that each version has its own address, its own title and description, and a canonical tag that points to itself and not to the other language.

What you receive

A short report written for the owner of the business, not for a developer. No export of hundreds of warnings from a tool.

Every finding has evidence, the URL where it happens and the date I saw it. Findings are ordered by priority: what costs you visitors now comes first, what is cosmetic comes last. Each fix has the hours it takes and who should do it: you, your developer, or me.

The free website review is a shorter first look at the main problems. The full audit is the first month of any monthly plan, or part of the setup, and the fixes continue in the months after it.