Pages get crawled
Crawl budget spent on pages that matter rather than on infinite URLs.
Freelance Technical SEO Expert in Bangalore
Making sure a search engine can reach, render and understand the site.
Content cannot rank on a page that is never crawled, never rendered or never indexed. Technical SEO is the layer underneath everything else, and on modern JavaScript sites it is where the quiet, expensive problems live.
- Any platform, including headless
- Rendering checked, not assumed
- Fixes implemented and verified
- Replies within one working day
Overview
What the technical layer actually covers.
Four questions, in order. Can a crawler reach the page. When it does, does it see the content or an empty shell. Having seen it, does it index it. And is the page fast and stable enough that the experience is not itself a problem. Fail the first and nothing else matters.
On a traditional server-rendered site these are mostly settled. On a React, Vue or headless build they are not. Content assembled in the browser may or may not be seen, depending on how rendering is configured, and the gap between what you see and what a crawler sees is where months of unexplained underperformance come from.
Indexation is its own category. Pages can be reachable and renderable and still excluded – by a stray noindex, a canonical pointing elsewhere, a robots rule nobody remembers adding, or simply because Google decided they were not worth it. Search Console says which, and reading it properly is most of the job.
Core Web Vitals belong here too, with one caveat worth stating: they are a real but modest ranking factor, and they matter far more for conversion than for position. Anyone selling a perfect score as a ranking strategy is overselling it.
What I offer
TechnicalSEO
01
Crawl and render audit
The site as a crawler sees it, including what JavaScript does and does not produce.
The gap between your view and Google’s, measured.
02
Indexation diagnosis
Why pages are excluded, page by page, from Search Console rather than from guesswork.
The actual reason, not a theory.
03
JavaScript rendering
Server-side rendering, prerendering or hydration problems on React, Vue and headless builds.
Content that exists for crawlers as well as for users.
04
Core Web Vitals
LCP, CLS and INP traced to their real causes and fixed in the build.
Field data that improves, not just a lab score.
05
Structured data
Schema written to specification, validated, and kept matching the page.
Markup that earns rich results instead of warnings.
06
Migrations and redirects
URL changes mapped properly, before launch rather than after the traffic drops.
A replatform that does not cost a year of rankings.
Key benefits
What fixing the technical layer changes.
Six things, none of which is a promised position.
Content gets seen
What renders for a crawler verified rather than assumed.
Pages get indexed
Exclusions diagnosed individually and resolved.
The site gets faster
Real causes fixed, measured in field data.
Markup that validates
Schema matching the page, so it keeps working.
Migrations survive
Redirects mapped before launch, not reconstructed after.
Who this is for
Who needs this.
Usually sites where content is good and performance is not.
JavaScript-heavy sites
React, Vue, Next.js and headless builds where rendering is the question.
Sites that lost traffic suddenly
Where something changed and nobody established what.
Recently replatformed sites
Where a migration went live without a redirect map.
Large sites
Where crawl budget is a real constraint rather than a theory.
Sites with good content and no traffic
The classic signature of a technical problem.
WordPress sites
Covered here, but the WordPress-specific page goes deeper on plugins and themes.
Where I work
Technical SEO for businesses here.
Two patterns come up repeatedly in Bangalore. The first is a startup that built a beautiful single-page application and discovered, months later, that almost none of it is indexed – because rendering was never configured and nobody checked. It is an expensive discovery and entirely preventable.
The second is a site that was replatformed over a weekend with no redirect map. Traffic falls off a cliff, the agency blames the algorithm, and a year of accumulated ranking is sitting behind 404s. This is recoverable, and the recovery is mostly patient mapping rather than anything clever.
On performance, the honest local point is that your audience is largely on mid-range Android phones on variable connections. A site that scores well in a lab test on a fast machine can still be slow for the people actually using it. Field data is the number that matters, and it is the one most reports leave out.
SPA indexation checked
The common and costly startup failure.
Replatform damage recovered
Redirect maps rebuilt after the fact.
Mid-range Android reality
Field data, not a lab score on a fast laptop.
Diagnosis before quoting
The cause identified before any work is priced.
Serving Chennai, Bangalore, India, Canada, UK, USA, Dubai, Singapore.
Industries
Where technical work is usually the bottleneck.
Scale and JavaScript are the two predictors.
SaaS & startups
Typically needs: Application-style sites built without rendering considered.
How I help: Rendering fixed so marketing pages are actually indexable.
E-commerce
Typically needs: Catalogue scale and faceted URLs.
How I help: Crawl control, canonicals and template-level speed.
Publishers
Typically needs: Large archives with crawl and pagination problems.
How I help: Pagination handled, old content kept reachable.
Marketplaces
Typically needs: Generated pages at scale, thin and duplicated.
How I help: Index management and consolidation.
Enterprise sites
Typically needs: Years of migrations layered on each other.
How I help: Redirect chains untangled, canonicals rationalised.
Headless builds
Typically needs: Content in an API and uncertain rendering.
How I help: Server rendering or prerendering verified against real crawls.
How I work
How a technical engagement runs.
Six steps, and it begins with what a crawler actually receives.
Discovery
I crawl the site as a search engine does, compare rendered output against source, and read Search Console coverage properly.
Planning
Findings are ranked by effort against effect. Some will be urgent, some cosmetic, and some not worth doing.
Design
Where rendering is the problem, the approach is chosen: server-side rendering, prerendering, or fixing hydration.
Development
Implementation: crawl rules, canonicals, redirects, schema, rendering and the performance work, in the codebase.
Testing & SEO
Verification: refetch, confirm what renders, check index coverage moves, revalidate schema, measure field data.
Launch & support
Monitoring: coverage, Core Web Vitals and crawl stats watched, with alerts when something regresses.
Technology
What I work across.
Platform-agnostic by design – the questions are the same, the levers differ.
Diagnosis
Search ConsoleCoverage, crawl stats and the rendered view.
CrawlersThe site as a bot receives it, with JavaScript on and off.
Field performance dataWhat real users experience, not a lab score.
Log filesWhat crawlers actually requested, where available.
Platforms
React, Vue, Next.jsRendering, hydration and routing.
ShopifyWithin the platform’s URL and template constraints.
Headless CMS buildsWhere content and rendering are decoupled.
Custom PHP and LaravelServer-rendered applications.
The work
Crawl and index controlRobots, canonicals, meta rules.
RedirectsMapped, tested, chains removed.
Structured dataWritten to spec and validated.
Core Web VitalsTraced to cause and fixed in the build.
Features
What an engagement includes.
Diagnosis, implementation and proof.
Render comparisonSource against rendered, with JS on and off.
Index diagnosisPer-page exclusion reasons.
Crawl controlRules written down and applied.
Canonical strategyDeliberate, not plugin defaults.
Redirect mappingTested before launch.
SchemaValidated and matched to the page.
Core Web VitalsField data, with causes named.
VerificationProof each fix took effect.
MonitoringRegressions caught after deploys.
SEO & performance
How this sits beside the WordPress page.
This page is platform-agnostic: React, Shopify, headless, custom builds. If your site is WordPress, the WordPress Technical SEO page goes further into the specifics – plugin conflicts, theme rendering, and the particular ways WordPress sites break.
The underlying discipline is identical. The difference is which levers exist and which problems recur, and those differ enough to be worth separate pages.
- Crawlability before anything else
- Rendering verified rather than assumed
- Indexation diagnosed per page
- Canonicals decided deliberately
- Redirects mapped and tested
- Core Web Vitals from field data
- Schema validated against the spec
- No guaranteed rankings
AI search
Why the technical layer matters to AI crawlers too.
AI crawlers have the same basic requirement as search crawlers and rather less patience: content present in the served HTML. A site that depends on client-side rendering is frequently invisible to them. Nobody can promise inclusion in any AI product, but a site that cannot be read certainly will not be.
- Content in the served HTML, not assembled in the browser
- Semantic elements rather than nested containers
- One clear subject per page
- Structured data matching the visible content
- Reasonable response times for crawlers
- No claim made about inclusion in any AI product
Why me
Why bring this to me.
Four things that separate a diagnosis from a document.
I fix what I find
Twelve years of building sites means the findings get implemented rather than handed to a developer who has other priorities. Most technical audits die at that handover.
I check rendering rather than assume it
The single most common unexamined assumption on a modern site, and the one that quietly costs the most.
Every fix is verified
Refetched, coverage checked, schema revalidated. A fix nobody confirmed is a line on an invoice.
Honest about Core Web Vitals
They are a modest ranking factor and a significant conversion factor. I will not sell you a perfect score as a ranking strategy.
FAQ
Questions I get asked about technical SEO.
Very likely. If content is assembled in the browser and rendering was never configured for crawlers, pages can be reachable and effectively empty when fetched. It is the most common expensive problem on modern builds, and it is testable in minutes.
Same discipline, different platform. This one covers React, Shopify, headless and custom builds. The WordPress page goes deeper into plugin conflicts and theme rendering, which are specific enough to deserve their own page.
Modestly. They are a real signal and they are not the main one. Where they matter far more is conversion – a slow site loses people regardless of where it ranks. I would fix them for that reason first.
Usually a substantial part of it, if the cause was missing redirects – which it most often is. The work is patient mapping of old URLs to new ones rather than anything clever.
How much attention Google gives your site. On a few hundred pages it is not a constraint. On a large store generating thousands of filter URLs it very much is, because the attention goes to pages that could never rank.
Yes, and I will give them specific changes rather than a list of findings. Where it is faster for me to implement directly, I will offer that instead.
No. It removes the reasons a page cannot rank. Whether it then does depends on content and competition, which are different problems with different work attached.
Usually a week for the diagnosis, depending on size. Implementation depends entirely on what is found – and some findings are a config change while others are an architectural decision.