Technical SEO

Site audits, Core Web Vitals improvements, indexation fixes, and schema implementation.

Technical SEO gets sold as a checklist and bought as reassurance. In practice it is diagnostic work, closer to reading a stack trace than filling in a form, and one question matters: what specifically is stopping search engines and AI crawlers from storing and using your pages.

My background is in computer science, at the Institute of Science and Technology under Tribhuvan University, before I moved into search. That matters more here than anywhere else on this site, because the work is reading server responses, rendered DOM output and log-style data rather than writing copy.

Crawl waste, not crawl budget, is the real problem on small sites

Site owners worry about crawl budget after reading that Google limits how much it will fetch. For a site under a few thousand URLs, budget is almost never the constraint. Crawl waste is.

Waste means Googlebot spending its visits on URLs that should never have existed: parameter variants, session identifiers, paginated archives with no unique content, staging subdomains left crawlable, tag pages generated automatically by a CMS nobody configured. Your important pages get crawled less often not because a quota ran out, but because they are buried in noise.

The fix is unglamorous. Decide which URLs are canonical, make everything else redirect, return a 410 or get blocked properly, then point the internal link graph clearly at what matters. I measure the result by how quickly newly published pages get discovered afterward, which beats any crawl budget statistic.

Five failures behind most pages Google never indexes

Canonical tags pointing at the wrong URL

Self-referencing canonicals get generated correctly by most modern platforms and then broken by a plugin, a template variable, or a migration. When every product variant canonicals to the category page, you have quietly told Google to discard your entire catalog. This is the single most common serious defect I find.

Content that only exists after JavaScript runs

Client-side rendered content can be indexed, but rendering is deferred and unreliable at the edges. If your main copy, your internal links or your structured data only appear after a script executes, you are gambling. I check the raw HTML response against the rendered output and flag anything that exists in one but not the other.

Duplicate templates with four sentences of variation

Pages sharing the same headings, structure and boilerplate read to a search engine as one page repeated. Location pages, service pages and product variants are the usual offenders. The fix is not a synonym pass. Each page needs genuinely different substance, or it should be consolidated into one strong page.

Orphaned and near-orphaned pages

Pages reachable only from the XML sitemap get treated as low priority, because nothing on the site suggests they matter. I map internal link depth from the homepage and surface anything sitting three or more clicks away that has commercial value. Fixing this overlaps directly with the content and keyword side of the work, since link architecture should follow the keyword map rather than the navigation menu.

Soft 404s and thin pages the CMS produced by itself

Empty category archives, author pages with one post, filtered views returning no results with a 200 status code. Each one teaches Google that URLs on your domain are frequently worthless, and that judgment does not stay contained to the pages that earned it.

Reading a Search Console coverage report without panicking

Coverage reports produce alarming totals that often mean nothing. "Excluded by noindex tag" is usually correct behavior. "Alternate page with proper canonical tag" is the system working. "Duplicate without user-selected canonical" means Google disagreed with your signals and picked its own winner, which is worth investigating.

The two I always dig into are "Discovered, currently not indexed" and "Crawled, currently not indexed". The first means Google knows the URL exists but has not prioritized fetching it, which points at site quality, internal linking or server response times. The second means it looked, evaluated and declined, which points at duplication or thin value. Different problems, different fixes, and conflating them wastes months.

I also sample URLs through live inspection rather than trusting the aggregate, because the aggregate lags and the sample tells you what is true today.

The Core Web Vitals work worth paying for, and the part that is not

Page experience signals are real and modest. Chasing a perfect Lighthouse score is a hobby, not a strategy.

What I do prioritize: Largest Contentful Paint on templates that receive organic traffic, because a slow hero image on your top landing page costs you conversions regardless of what it does to rankings. Cumulative Layout Shift caused by ads, embeds or web fonts loading late, because that is a genuine user harm. Interaction responsiveness on mobile for anything with a form.

What I usually deprioritize: shaving milliseconds off pages nobody lands on, refactoring a theme to remove render-blocking CSS on an otherwise healthy site, and any optimization costing more to implement than the traffic it might earn. I will tell you when a performance item is not worth your developer's time, which is a strange thing for a consultant to argue and the reason I bring it up.

Structured data now decides whether AI assistants can read you

Schema markup used to be about rich results in Google: star ratings, FAQ dropdowns, recipe cards. Those still matter, but the more consequential change is that large language model systems and AI search products depend on being able to parse what a page is, who published it, and what factual claims it makes.

An assistant summarizing your industry has to resolve several things fast. Is this page about an organization, a product, a service or a person. Who is the author, and does the site say anything about their expertise. What is the price, the location, the publication date. Structured data answers that in machine-readable form instead of leaving it to be inferred from prose.

Crawl health matters here too, and it is often overlooked. Several AI crawlers are separate user agents from Googlebot, and a robots.txt written years ago may be blocking them entirely. If a system cannot fetch your page, it cannot cite it, and no amount of content quality compensates for a disallow rule.

The honest limits matter. Nobody can guarantee that ChatGPT, Perplexity, Claude or Google's AI Overviews will cite a given site. These systems are non-deterministic, their source selection changes, and none of them sell inclusion. What you can do is remove the reasons to be excluded: make the site crawlable by the relevant agents, mark up entities consistently, state facts plainly and in extractable form, keep your business details identical across the web, and earn mentions on sources these systems already trust. That sits at the intersection of this page and structured data as the layer AI crawlers read, where I cover the content and citation side in more depth.

What the audit document looks like, and who I write it for

Most technical audits are a crawler export with a logo on the front. Several hundred rows, no prioritization, no implementation detail, and a client who has no idea what to do on Monday morning.

Mine is written for two readers at once. For you, a short summary in plain language explaining what is broken, what it is costing, and what order to fix it in. For your developer, the specific file, template, rule or setting to change, the expected result, and how to verify it went live correctly. No item goes in without both.

I spent time teaching computer science to class eleven students at Supreme College, and that habit of translating a technical idea for someone who has not seen it before carries directly into this deliverable. If you finish reading my audit and still need a call to understand what to do, I wrote it badly.

Migrations and replatforms, the fortnight that decides your next year

Site migrations are where technical SEO earns or loses more traffic than anything else, and they are almost always scheduled with no SEO input until the week before launch.

What I do on a migration: crawl and archive the existing site before anything changes, build a complete old-to-new URL mapping including the pages nobody remembers, verify redirects are single-hop 301s rather than chains, confirm the staging environment is not indexable and the live one is, and monitor indexation and rankings daily for the first weeks afterward. Analytics and tag continuity get checked in the same pass, since a migration that keeps rankings and loses GA4 and GTM implementation still leaves you blind.

What I do not take on

I do not rebuild your site. I do not write custom application code, manage your hosting, or take responsibility for deployments. I work alongside whoever owns the codebase, or I implement directly in a CMS like WordPress where that is appropriate.

I also will not run a technical retainer on a site with no technical problems left. Once the crawl is clean and the fixes have shipped, ongoing spend belongs in content and search strategy, and I will say so rather than invent work.

You can see sites where I have fixed indexing problems, and if you are weighing this against an agency contract, why a small business rarely needs a full agency for this sets out the tradeoff. When you are ready, book a technical audit and send me read access to Search Console. I will usually know within a day whether the problem is indexing, duplication or rendering.

Frequently asked questions

Why are my pages not being indexed by Google?

The most common causes are canonical tags pointing at a different URL, content that only appears after JavaScript renders, near-duplicate templates across many pages, pages linked only from the sitemap, and soft 404s returning a 200 status. Search Console distinguishes "discovered, currently not indexed" from "crawled, currently not indexed", and those two states have different fixes.

How much does a technical SEO audit cost?

Technical audits are quoted as a fixed price based on site size, platform and how many templates need review, not by the hour. The quote is given before work starts and does not change mid-project. Audit pricing is quoted on request once I have seen the site.

Do I need a developer to implement your recommendations?

Usually yes for custom builds, and often no for WordPress or similar platforms where I can implement directly. Every recommendation is written with the specific file, template or setting to change and how to verify it, so a developer can action it without a briefing call. I then re-check the live site to confirm the fix deployed correctly.

Does structured data help my site appear in ChatGPT or AI Overviews?

It helps by making your entities, authorship, pricing and factual claims machine-readable, and by ensuring AI crawlers are not blocked in robots.txt. It does not guarantee anything. AI systems select sources non-deterministically and none of them sell inclusion. The realistic goal is removing the reasons a system would skip you.

Is Core Web Vitals still worth fixing in 2026?

Selectively. Largest Contentful Paint on your organic landing templates and layout shift caused by late-loading ads or fonts are worth fixing because they harm users as well as rankings. Pursuing a perfect performance score across pages that receive no traffic is rarely worth the developer time it consumes.

Can you help with a website migration or replatform?

Yes, and the right time to involve me is during planning, not the week of launch. The work covers a pre-migration crawl and archive, a complete old-to-new URL map, single-hop 301 redirects instead of chains, staging kept out of the index, and daily monitoring of indexation, rankings and analytics continuity after go-live.