Short answer, if that is all you need: technical SEO makes your site eligible to rank. It covers crawling, indexation, rendering, speed, structure and migrations. Useful first checks include a leftover noindex, changed URLs without redirects, and important content missing from the initial HTML. Each condition is directly testable before recommending a fix.

What this covers

This page is the engineering half of search. If you want the commercial overview, the map pack, or answer engines specifically, those live on SEO consulting, local SEO and GEO and AEO respectively. What follows is the part that decides whether any of those have a chance.

1. Crawl and indexation

The first question is not how well you rank. It is whether Google has the page at all. I work through Search Console's index coverage data and a full crawl of the site, and the answer is usually one of a short list: pages returning the wrong status code, canonical tags pointing at a different URL, redirect chains that lose signal at each hop, a sitemap listing URLs that no longer exist, or a robots.txt rule blocking something important.

A noindex tag left behind from a staging build is one failure worth checking immediately. A developer may set it during development so the unfinished site does not get indexed, then launch without removing it. The site can look correct in a browser while explicitly asking search engines not to index it.

2. Rendering, which is where modern builds fail

A site built as a single-page application in React or Vue without server-side rendering can look flawless in a browser and deliver an almost empty document to anything that does not execute JavaScript. Google does render JavaScript, but rendering is a separate stage after crawling; its JavaScript SEO guidance explains the processing sequence and why server-side or pre-rendering remains useful.

Other crawlers vary in how they process JavaScript. If important content only exists after hydration, some systems may not see it reliably. I compare the raw HTML response with the rendered page rather than assuming every crawler executes the application the same way.

3. Core Web Vitals, measured how your visitors experience them

Speed is a modest ranking factor and a large revenue factor. The distinction matters because it changes what is worth fixing.

If your analytics show substantial mobile traffic, test on representative mobile hardware and variable network conditions. A page that feels instant on office fibre may behave differently elsewhere. I use field data where available rather than treating a desktop lab score as the user experience.

Images are a common cause: uncompressed hero photographs, full-resolution originals scaled down in the browser, missing dimensions, or lazy loading applied to the LCP image. Test the LCP element, network waterfall, and main-thread work before deciding whether image delivery, scripts, application code, or hosting deserves priority.

4. Migrations and redirect recovery

A redesign can damage search visibility when URLs change without redirects. Compare the old crawl or sitemap with the new site before launch, preserve valuable URLs where possible, and map changed pages to their closest equivalents.

If this has already happened, map each valuable old URL to its nearest new equivalent, implement proper 301 redirects, update internal links and sitemaps, then monitor indexing and search performance. Recovery timing and completeness depend on the migration and cannot be guaranteed.

If you are planning a redesign, this is the cheapest hour you will ever spend with me, and it should happen before anything is built rather than after launch.

5. Index bloat and duplication

The opposite problem to not being indexed is having far too much indexed: tag archives, paginated duplicates, search result pages, staging copies left live, and the same content reachable at several URLs at once. This dilutes which page Google treats as the real one and wastes crawl budget on pages that will never earn anything. The fix is deciding what deserves to exist, then consolidating or removing the rest properly.

6. Structured data

Schema markup does not make weak content rank. What it does is remove ambiguity about what a page is, which matters more every year as answer engines assemble responses from structured sources. I implement the types that earn something back — Organization or LocalBusiness, Service, Article, BreadcrumbList, FAQPage where there are genuine questions, and Product for stores — and validate them rather than assuming.

Two rules that get broken constantly. Google's structured data policies require marked-up content to represent visible page content; hidden FAQ markup can make a page ineligible for rich results. And prices must carry NPR, not the USD left in place from whatever international template the markup was copied from.

7. Hosting and time to first byte

Server location is a weak ranking signal, and the belief that a Nepali site must sit on a Nepali server is mostly folklore. What matters is measured response time. A well-configured international host behind a CDN with a South Asian edge will frequently serve Kathmandu visitors faster than a cheap local shared server that is oversubscribed. I measure before recommending a move, and quite often the correct answer is to keep the host and put a CDN in front of it.

How I work on this

Engagements start with a paid audit that produces a written, prioritised list: what is broken, what it is costing, what it takes to fix, and in what order. That document is useful whether or not you continue with me, and it is deliberately written so your own developer can act on it.

Where you would rather I implement, I do. Being a developer as well as an SEO is the reason this page exists as a separate service: most technical SEO reports in this market die in an inbox because the person who wrote them could not ship the fix and the person who could ship it did not understand the report. My published 60-minute SEO audit checklist is the same sequence I run, so you can see the method before hiring anyone, including me.

Common questions

Why is my website not showing on Google at all?

Check for a leftover noindex, a robots.txt block, important content missing from the initial HTML, or misdirected canonicals. URL Inspection and a raw HTML fetch test these directly; larger sites may require a broader crawl.

We redesigned and lost our traffic. Can it come back?

It may. Compare old and new URLs, redirects, canonicals, internal links, content, and indexation. Fix verified migration errors and monitor recovery rather than relying on a fixed timeline.

Does speed really affect rankings here?

Speed is one ranking input and can also affect user behaviour. Use your own device, network, and conversion data to prioritize fixes; image weight is a useful first check when the LCP element is an image.

Do I need Nepali hosting?

No. Optimise for measured time to first byte, not for where the server sits. A CDN in front of a good international host normally beats cheap local shared hosting.

Should I use hreflang?

Only if you genuinely maintain both English and Nepali versions of the same pages. Half-implemented hreflang pointing at pages that do not exist is worse than none.

Technical work makes you eligible; it does not by itself close an authority gap. See SEO consulting in Kathmandu for the full picture, local SEO if you have a physical location, and web development if the honest answer is that the site needs rebuilding rather than repairing. Full list of services.

Send me the URL and the symptom

Tell me what you expected to happen and what is happening instead. Most technical problems are identifiable from the outside, and I will tell you what I find before there is any question of an invoice.

Get in touch Book a consultation