SERVICE / 03
Technical SEO Services
Technical SEO is the layer that decides whether anything else you do in search can work. I diagnose how Google crawls, renders and indexes your site, fix the structural problems that cap it, and work directly with your developers so the fixes actually ship and stay shipped.
On this page
Every page on your site has to pass through the same sequence before it can earn a single visit: Google has to discover the URL, fetch it, render it, decide it is worth indexing, and then decide it is the best answer for a query. Most technical SEO problems are a failure somewhere in that chain, and most of them are invisible from a browser.
- Discover
- Crawl
- Render
- Index
- Rank
My technical SEO work is about making that chain reliable at scale, and then keeping it that way as the site changes.
What technical SEO covers
People sometimes reduce technical SEO to page speed, or to "fixing errors in a crawler". It is wider than that: the set of decisions about how a site is built that determine what search engines can see and how they value it. Some live in code, some in CMS configuration, and some in information architecture that nobody thinks of as technical until it breaks.
Crawling and indexing
Robots directives, sitemaps, crawl budget on large sites, parameter handling, faceted navigation, index bloat from thin or duplicate URLs. Covered in depth in my guide to crawlability and indexability.
Rendering and JavaScript SEO
Whether the content Google indexes matches the content users see. Client-side rendering, hydration, lazy-loaded content, and the second-wave rendering delay. See JavaScript SEO and the rendering experiment in the lab.
Site architecture
How URLs are organised, how deep important pages sit, how categories, hubs and leaves relate. Architecture is the structural ceiling on how many pages can rank. My guide to site architecture goes into the trade-offs.
Internal linking
How authority and crawl paths move through the site. On most large sites this is the single biggest technical lever, and the least deliberately managed. I built the Internal Linking Framework around it.
Core Web Vitals and performance
LCP, INP and CLS, measured on real users rather than lab scores, and prioritised by which templates and which devices actually have a problem. Explained in Core Web Vitals.
Canonicalisation and duplication
Canonical tags, hreflang, trailing slashes, HTTP and HTTPS, www and non-www, tracking parameters, and all the other ways one page becomes six.
Log file analysis
What Googlebot actually requests, how often, with what response codes. Logs are the only source of truth for crawl behaviour; everything else is inference.
Migrations
Domain changes, replatforms, framework rewrites, URL restructures. Planned before the build, tested on staging, monitored after launch. The highest-risk moment in a site's organic life.
Who needs technical SEO work
Large and templated sites
Marketplaces, classifieds, e-commerce, listings, publishers. Problems live in templates and multiply. One wrong canonical rule can remove a hundred thousand pages from the index. This is where technical SEO at scale earns its keep.
JavaScript-heavy products
React, Next.js, Vue, Angular, Flutter web. Sites where the HTML Google first receives is nearly empty and everything depends on rendering. These need a rendering strategy, not a plugin.
Teams planning a migration
Anyone about to change domains, platforms, frameworks or URL structures. The best time to engage is before the architecture is decided, not the week before launch.
Sites with unexplained indexing gaps
You publish pages and they do not get indexed, or they get indexed and then drop out. Search Console says "crawled, currently not indexed" and nobody knows why.
Companies whose content investment is underperforming
Good content on a site with structural problems does not rank. If you have invested in content and the needle has not moved, the technical layer is the first place to look.
The problems this solves
Pages that are not indexed, or not indexed reliably. Usually a combination of weak internal linking, crawl budget wasted on parameters or faceted URLs, and templates that give Google little reason to keep the page. The orphan page experiment in the lab looks at what actually moves indexing for pages with no inbound links.
A rendering gap. The page looks fine in a browser but the HTML Google indexes is missing the product description, the reviews, the internal links or the whole main content. This is common on Indian D2C and SaaS sites built on modern frameworks, and it quietly caps growth for months before anyone notices.
Crawl budget spent on junk. On large sites I regularly see most of Googlebot's requests going to filter combinations, sort parameters, session URLs and paginated series that should never have been crawlable. Meanwhile new product pages wait days to be discovered.
Authority that never reaches the pages that matter. The homepage has all the links; the category and product pages three clicks down have almost none. Architecture and internal linking fix this, and the internal linking at scale experiment shows how much it can move.
Migration losses. Redirect maps that miss long-tail URLs, canonicals pointing at the old domain, staging robots rules shipped to production, rendering changes nobody tested. All avoidable with a checklist and a staging crawl.
How I approach technical work
I start from evidence, not from a checklist. The crawl, Search Console's index coverage and page experience reports, and server logs are read together, because each one alone misleads. A crawler shows what is linked; logs show what Google actually fetches; the index report shows what it kept. The interesting findings are in the gaps between the three.
Then I look for root causes at the template level. On a site with a million URLs there are perhaps twenty templates. A problem fixed in a template is fixed everywhere; a problem fixed page by page is a job for life. The audit framework describes how I structure this.
Every recommendation is weighed against engineering cost. Developers have a roadmap of their own and a change that takes a sprint had better be worth a sprint. I prioritise the way I describe on the audit page: by impact on crawl, index and rank, against realistic effort, with dependencies made explicit.
Working with development teams
Technical SEO fails when it is handed to developers as a document. It works when it is handed to them as tickets with acceptance criteria, a staging environment to test on, and someone who reviews the output before and after deploy. That is how I work: in your issue tracker, in your sprint planning, in your pull requests where the team is comfortable with that.
I also try to leave the team with rules rather than fixes: a URL policy, a canonical rule set, a rendering standard for new components, a pre-launch checklist. The goal is a system that does not regress every time someone ships a feature. This is what I mean by the implementation problem.
India-specific considerations
Most of the Indian web is consumed on mid-range Android devices over mobile networks that are fast in metros and inconsistent everywhere else. Google's mobile-first indexing means the mobile version of your page is the one that counts, and lab scores from a laptop on fibre tell you very little. I test on real-device profiles and throttled connections, and I prioritise mobile templates over desktop ones.
Hindi and regional-language content raises its own technical questions: URL structure, hreflang, transliterated versus native-script keywords, and font loading that does not wreck CLS. Much of this work happens with product and engineering teams in Bangalore and Hyderabad.
What you get
Technical diagnosis
A written account of how Google currently crawls, renders and indexes the site, with evidence from crawl, logs and Search Console, and the specific constraints found.
Prioritised technical backlog
Every finding as a ticket-ready item with impact, effort, affected templates, acceptance criteria and verification steps.
Architecture and URL recommendations
Where structure needs to change: hierarchy, URL patterns, pagination, facets, hub and cluster design, with the reasoning.
Rendering strategy
For JavaScript sites: which rendering approach fits which templates, what must be in the initial HTML, and how to test it. Grounded in the JavaScript SEO guide.
Internal linking specification
Rules for how pages link to each other by template, so authority and crawl paths are managed deliberately rather than by accident.
Migration plan and checklist
Where relevant: URL inventory, redirect map, staging test plan, launch-day checks and a monitoring schedule for the weeks after.
Implementation review
Staging checks before deploy, log and index checks after. Regressions caught before they become a traffic drop.
Process
Scope and access
Search Console, analytics, CMS, staging, logs, and a conversation with whoever owns the codebase. I want to understand the stack and the deploy process before I recommend changes to either.
Crawl, render, log
A full crawl, a rendered crawl where JavaScript is involved, and a log sample long enough to see Googlebot's real behaviour. For large sites, segmented by template.
Diagnose at template level
Findings traced to root causes in templates, configuration or architecture, not listed per page. Each one checked against index status and logs so we are fixing what Google actually cares about.
Specify and prioritise
Tickets with acceptance criteria, sequenced by impact and effort, with dependencies. The team gets a backlog, not a PDF.
Implement and verify
I review on staging, confirm after deploy, and watch logs and index coverage for the following weeks. Then we move to the next block of work.
Codify
Rules, checklists and documentation so the site does not regress. This is the step most engagements skip and the one that makes the work compound.
Examples
Technical SEO and content architecture (Rahul Verma, Finance) — crawl cleanup and topical restructuring that scaled organic traffic from 8k to 45k monthly visits.
Programmatic and catalog SEO build (Anil Sharma, Sentiment Furniture Systems) — category architecture, crawl control, and regional targeting that produced page-one NCR rankings and organic orders in 3 months.
Frequently asked questions
Do you implement the changes yourself or just recommend them?
I specify, review and verify. Your developers implement, because they know the codebase and the deploy process. For some CMS platforms I can make configuration-level changes directly if that is useful. What I will not do is hand over a document and disappear; I stay through implementation.
Our site is built on React or Next.js. Is that a problem for SEO?
Not inherently. The question is what Google receives in the initial HTML and how much depends on client-side rendering. Server-side rendering or static generation for indexable templates solves most of it. I test what Google actually renders rather than assuming, and recommend a rendering approach per template.
How quickly do technical fixes show results?
Faster than content work, usually. Indexing fixes can show within days to weeks once Google recrawls. Architecture and internal linking changes take longer as authority redistributes. Core Web Vitals improvements take about a month to reflect in field data. I give a range per fix and I do not promise dates.
Can you help with a migration that has already gone wrong?
Yes. Recovery starts with a before-and-after comparison: which URLs lost traffic, whether they redirect correctly, whether they render, whether they are indexed. Most migration losses are a few compounding issues that can be fixed quickly once identified. The sooner after launch, the better.
Is Core Web Vitals work worth it?
Sometimes. Page experience is a modest ranking factor, but speed matters a lot for conversion on mobile in India, and some templates have genuine failures that are cheap to fix. I prioritise performance work by the revenue of the affected templates, not by lab score, and I will tell you if it is not the first thing to do.
Fix the layer everything else depends on
If pages are not being indexed, a migration is coming, or a modern framework is doing things to your HTML that nobody has checked, start here. Send me the domain and what you are seeing.
Work with me
Have a technical problem nobody can name?
Send me the domain and what you are seeing. I will tell you what I would check first and whether it needs a full engagement or a short diagnosis.
Work With Me Read the technical SEO guide