Crawl
A full crawl of the site as a search engine sees it, compared against your sitemap and against what is actually indexed.
SEO · Delhi NCR & remote
Technical SEO is the least glamorous part of the discipline and the one most likely to be the actual problem. It is also the part a developer can fix properly and a content agency usually cannot.
Short answer
Technical SEO makes a site crawlable, indexable and fast: fixing crawl errors, index coverage, canonical tags, redirect chains, sitemaps, robots rules, Core Web Vitals, mobile rendering and structured data. It rarely creates rankings on its own, but it is what allows everything else to work.
Four details. A real reply the same day, from me.
01 The premise
A site can have excellent content and rank for none of it. The reasons are almost always mechanical: pages blocked in robots.txt, canonical tags pointing at the wrong URL, a redirect chain four hops long, the same content reachable at six addresses, or content injected by JavaScript that the crawler never renders.
These faults share an unhelpful property — the site looks completely fine to you. You visit your own pages in a browser and everything works. The damage is only visible in what Google has actually indexed, which is why the first thing I look at is never the site itself but Search Console’s coverage report and a full crawl.
It is also why technical SEO usually needs a developer rather than a marketer. The fixes are in code, in server configuration and in templates. An agency that can identify the problem but has to file a ticket with your developer to fix it is a slow and lossy way to solve this.
02 The checklist
Roughly in the order that faults cost you traffic.
03 Speed
These are user-experience measurements. Google uses them, but the reason to fix them is that they are real.
| Metric | What it means and what usually causes it |
|---|---|
| LCP — Largest Contentful Paint | How long until the main thing appears. Usually ruined by an oversized hero image, render-blocking CSS or slow hosting. |
| CLS — Cumulative Layout Shift | How much the page jumps while loading. Almost always images without dimensions, late-loading fonts, or an ad slot with no reserved space. |
| INP — Interaction to Next Paint | How quickly the page responds to a tap. Caused by heavy JavaScript running on the main thread — frequently third-party scripts nobody audits. |
| TTFB — Time to First Byte | How long the server takes to respond at all. A hosting and database question more often than a code one. |
Free technical audit
Send me the URL and Search Console access if you have it. I will tell you what Google has actually indexed, what it has rejected and why — which is frequently a surprise.
Four details, and a real reply today.
04 Process
A full crawl of the site as a search engine sees it, compared against your sitemap and against what is actually indexed.
Sorted by traffic at risk, not by severity in a tool. A critical warning on a page nobody visits is not urgent.
Server, template and code changes. Done by the person who found them, which removes the slowest step in most engagements.
Re-crawled, re-tested, and re-submitted. A fix that was not verified in Search Console is a fix you are assuming.
Coverage and vitals watched for a period afterwards, because regressions arrive through ordinary content edits.
— SEO
These sit next to technical SEO and are usually bought with it. Same person doing the work in each case.
Rankings that hold.
Read moreWin the map pack.
Read moreCategory and product pages.
Read moreThousands of URLs, many owners.
Read morehreflang done properly.
Read moreYour sector’s own search behaviour.
Read more— Questions
Straight answers, including the ones that cost me work. If yours is not here, ask it — I reply the same day.
Everything that determines whether a search engine can reach, render, understand and trust your pages — crawling, indexing, canonicals, redirects, speed, mobile rendering and structured data. It is separate from content and links, and it comes first because neither of those works without it.
The usual causes, in order: blocked by robots.txt or a noindex tag, a canonical pointing elsewhere, judged duplicate of another page, content that only exists after JavaScript runs, or simply not discovered because nothing links to it. Search Console’s coverage report names which one it is.
Yes, though less than people assume as a direct factor. Its larger effect is indirect: slow pages lose visitors before they read anything, which shows in every behavioural signal. On mobile, where Google measures, the difference between a two-second and a six-second load is commercially significant regardless of ranking.
It rarely changes rankings by itself. What it does is make you eligible for richer results — FAQs, breadcrumbs, products, reviews — and it tells engines unambiguously what a page is, which increasingly matters for AI-generated answers. It is cheap to add and worth having.
It can be. If content is rendered only in the browser, crawlers may see an empty shell. Server-side rendering or pre-rendering solves it. The way to know is to fetch the page as Google does and look at what actually comes back, rather than assuming either way.
A full one annually, and always before and after a redesign, migration or platform change. Beyond that, watching Search Console coverage monthly catches most regressions early — they usually arrive through ordinary content edits rather than dramatic events.
Free consultation · No obligation
Send me your URL. You will get a prioritised list of what is broken, sorted by the traffic actually at risk — not a scanner score out of a hundred.
Name, number, email, what you need.