Technical SEO

Technical SEO is about whether search engines can find your pages, read them and decide which version to show. Most sites do not have dramatic technical problems, but many have a handful of quiet ones that hold everything else back. My work is to find those, rank them and describe the fix so a developer can act.

How search engines reach your pages

Search works in stages. A crawler discovers URLs, fetches the pages, processes what it finds, and the engine decides whether to include the page in its index and when to show it. A problem at any stage can keep a good page invisible.

Knowing which stage is failing saves a lot of effort. A page that is not crawled needs different help from one that is crawled but not indexed. I use search console reports, server behaviour, crawl tools and direct inspection of specific URLs to work out where the break is, rather than guessing from symptoms.

Plenty of owners assume indexing is automatic. It is not. A search engine decides how much of your site to crawl and which pages are worth storing, and it makes those choices from the signals it finds. Sites with duplicated pages, endless filter combinations or slow servers can waste that attention on pages that should never have been crawled in the first place.

A review that follows the evidence

I begin with what the search engine itself reports about your site, then crawl the site the way a bot would and compare. Differences between the two are often the most interesting findings: pages you want indexed but are not, pages indexed that should not be, and pages only reachable through odd paths.

I pay particular attention to the areas below, because they account for most of the real problems I see. Not every site has all of them. The review tells us which ones apply to yours.

This evidence-first approach keeps the review honest. I am not looking for problems to justify a fee but for explanations of specific symptoms, such as pages missing from results, traffic that dropped after a change, or new pages that take too long to appear. If the site is healthy, I will tell you so and suggest where your money is better spent.

One more point on method: I do not rely on a single tool's score. Crawlers, search console data and server logs each show a different slice of reality, and I cross-check them. A tool might flag a thousand warnings that do not matter while missing the one rule in your configuration that is blocking an important section. Judgement is still required.

• Crawl access: robots rules, blocked resources, login walls and pages that load only through scripts.
• Indexing signals: noindex tags, canonical tags, duplicate or near-duplicate pages and parameter URLs.
• Redirects and status codes: chains, loops, soft errors and old URLs still being linked to.
• Sitemaps: whether they list the right URLs and only those.
• Structure: depth of important pages, orphan pages and navigation that hides key content.
• Mobile rendering and page experience: layout, speed and anything that makes pages hard to use.

Priorities, not a long list

Audit tools produce hundreds of warnings, and most are harmless. Treating every warning equally wastes developer time and hides the two or three issues that matter. I sort findings by whether they affect pages that earn or could earn business, how many pages are affected and how hard the fix is.

The result is a short ordered list with the reason for each item. If a fix is cheap and the effect is plausible, it goes first. If it is expensive and speculative, it waits. This approach also protects you from paying for work that looks thorough but changes nothing.

I include effort and risk in every item, because some fixes touch templates that affect the whole site. Those need a staging test and a rollback plan. Others, like updating a sitemap, are low risk and quick. Putting the safe, useful items first builds momentum and shows your developers that the list is realistic.

The most useful technical audit is the one a developer can finish in a sprint.

Writing recommendations developers can use

A recommendation like 'fix canonical tags' is not enough. I write what is wrong, give example URLs, state the expected behaviour, describe how to test it and note any risk. Where the platform matters, such as a particular CMS or framework, I tailor the advice to it.

I can work with your internal developers, with an external team or with the person who manages your site. For agreed implementation I can handle some changes directly. Either way I check the result after release, because fixes that were not deployed as described are common.

Documentation travels with the recommendations. I explain why each change matters in plain language so that a non-technical owner can approve it, and I include testing steps so that anyone can verify the result. If your developer disagrees with a recommendation, I want to hear the reasoning, since they know the system better than I do.

Website migrations and redesigns

Migrations are where technical SEO carries the most risk. Changing domain, platform or URL structure without a mapping plan can strand years of accumulated visibility. I help plan URL mapping, redirects, content parity and launch checks, and I want to be involved before design is signed off, not after launch.

Even a carefully managed migration usually brings some fluctuation in search visibility, and I would not tell you otherwise. The aim is to avoid preventable damage, monitor closely after launch and fix problems quickly. If a redesign is coming, tell me early.

The planning for a migration begins with a full inventory of existing URLs and which of them earn traffic or links, then maps each to a destination. After launch I compare crawl and search data against the plan within the first days, to spot missing redirects or blocked pages while they can still be fixed quickly.

Speed, structure and structured data

Page speed matters most when it makes the experience poor for real visitors, especially on mobile connections. I look at what slows key pages, such as oversized images, heavy scripts and layout shifts, and recommend changes proportionate to the benefit.

Structured data can help search engines understand entities such as your business, services, articles and questions. I recommend it where it accurately mirrors visible content, and not as decoration. It also supports clearer business information, which links to the work described under AI search visibility.

Not every speed problem is worth fixing, and not every score on a testing tool reflects real visitor experience. I look at field data where it exists and focus on pages that matter commercially. A small improvement on a key page is worth more than a perfect score on an unimportant one.

JavaScript-heavy sites need extra care, since content that appears only after scripts run may be seen late or not at all. I test how key pages render for a crawler, and if the content is missing, we discuss options with your developers, from small changes to rendering approaches. This is a common reason for pages that exist but never perform.

When technical work is not the priority

If your site is crawled and indexed properly, spending months on technical refinement is a poor use of money. The gains will be small. The bigger opportunity is more likely in content, page relevance or your reputation beyond the site, and an SEO strategy will tell you which.

What I need from you to begin: the site platform, a list of recent changes such as redesigns or plugin updates, access to Search Console and analytics, and a developer contact. Technical SEO consulting is available within SEO consulting from ₹50,000 + GST per month, or as a scoped project.

Retainers for technical work usually run in bursts: a heavy first phase to fix the backlog, then periodic checks. I do not recommend paying every month for a technical audit of a stable site. A scheduled review each quarter, plus a check before and after any redesign, is generally enough.