Specialist work · Vadodara
Technical SEO
Crawl, render, index, performance, migrations and search architecture — written as tickets your developers can ship, not as a checklist export.
Fit
Who this is for
A fit
- Engineering-led teams who will actually ship template and infrastructure changes.
- Sites where the commercial URLs cannot be fetched, rendered or kept in the index reliably.
- JavaScript, headless or custom stacks where the HTML Google gets is not the page a user sees.
- Migrations, redesigns or CMS moves where current URL equity has to survive the cutover.
Not a fit
- A bundled “SEO package” of blog posts and links with a technical appendix nobody will implement.
- Sites whose real constraint is content strategy or a market they have not defined — start with consulting or an audit.
- Anyone who wants rank tracking as the deliverable and will not grant Search Console or codebase access.
Problems
What I diagnose
Fetch vs render vs index. Robots, sitemaps, status codes, canonicals and rendering each fail in different ways. Most “the site is not ranking” conversations are actually a break in that chain, and treating them as a content problem wastes months.
JavaScript SEO. The raw response is a shell; the product lives in a client render Google may not wait for, may not execute the same way twice, or may index in a state your QA never sees. That is a rendering-path problem, not a meta-tag problem.
Template-level waste. Parameter URLs, faceted crawls, duplicate templates and internal-link traps burn crawl budget on URLs that should never have been candidates. One template rule beats a thousand URL patches.
Performance as an afterthought. Largest Contentful Paint and layout shift are often locked into the template and the font/asset chain. I treat them as shipping constraints on the templates that carry commercial intent, not as a Lighthouse screenshot in a slide.
Migrations that orphan demand. A homepage 301 and a spreadsheet of “main pages” is not a migration. Query strings, paginated archives, expired products and the URLs Search Console still shows all have to be accounted for, or they become 404s with history.
Architecture that cannot grow. URL design, information architecture and internal links decide whether next year’s pages inherit signals or dilute them. That is engineering work. It does not come out of a keyword tool.
Delivered
What you actually get
Crawl map against index map
What exists, what Google kept, what was discovered and wasted, and where sitemap, robots and canonicals disagree. Evidence is URLs and exports, not adjectives.
Render comparison notes
Raw response versus rendered DOM on the templates that matter: which content, links and structured data appear only after JavaScript, and what that implies for indexation.
Ticket-ready fix list
Each High and Medium finding: affected URL pattern or template, evidence, severity, proposed change, owner (dev / ops / me), and the acceptance check that means it is done.
Redirect and cutover map
For migrations: source → target, status codes, chains to flatten, and a sequence that can be scheduled rather than hoped for. Includes the URLs nobody put in the design file.
Architecture brief
URL design, indexation rules per template, internal-link ownership, and what must not be invented later by a plugin default.
Every High finding is a ticket: URL or template, evidence, change, acceptance check. If it cannot be scheduled, it is not a finding yet.
Method
How the work runs
Access and constraints
Search Console, a crawl, production versus staging, and logs where they exist. I will tell you what I cannot see without access rather than infer it.
Isolate the break
Fetch, render, index, canonicalisation, then template behaviour. The order matters; fixing titles on URLs Google never keeps is theatre.
Template and architecture pass
Group findings by template and by system, not by individual URL. The unit of work is the thing your developers will actually change.
Spec
Write the tickets. Acceptance criteria are part of the spec, so “done” is observable in the HTML, the headers, or Search Console — not in a status meeting.
Verify
Recrawl the affected patterns, check rendering on the templates we touched, and read Search Console against the URLs that were supposed to move. Then re-prioritise.
Proof
Examples in progress
There is no published technical teardown on this site yet. I would rather show an empty shelf than a fabricated before/after.
When a migration map, render diff or indexation recovery is published, it will name the stack, the break in the fetch/render/index chain, what was actually shipped, and the limits of the evidence — with client permission.
Until then, the honest substitute is a conversation on your URLs: I will walk through what I can see publicly and what I would need access to prove.
Questions
Common questions
Do you need server logs?
They help when crawl budget or bot behaviour is the question, and I will use them when you have them. Many engagements can start from Search Console, a crawl and the rendered HTML. I will not invent log conclusions from a sample of URLs.
Can you work on a JavaScript or headless stack?
Yes. That is often the actual job: what is in the first response, what appears only after hydration, how the crawler is allowed to execute it, and which commercial content must be in HTML if you cannot rely on a render. I spec against your stack rather than asking you to “add a plugin”.
Do you implement, or only write tickets?
Both, depending on which is faster. I write developer-ready briefs as the default, and I implement directly where I can do that without a theatre of handoffs — particularly when the change is in templates, headers, sitemaps or redirects I can ship.
How is this different from an SEO audit?
An audit is a diagnostic product: evidence, severity, a backlog and acceptance criteria, then a walkthrough. Technical SEO is the project that follows when the work is crawl, render, index, performance, architecture or a migration. If you do not yet know which of those you have, start with the audit.
Bring the URLs that should be indexed and are not
Send the site, the stack if you know it, and the symptom. I will tell you whether this is technical work, an audit first, or not a search problem.