indiaseobriefs

Bangalore's residential market produces an enormous volume of search, and most developer websites capture almost none of it. The site exists to support a sales team: a homepage with a hero video, a projects listing, an enquiry form. Everything a buyer types goes to an aggregator instead.

That is a fixable problem, and the fix is mostly about building pages at the grain of the query rather than at the grain of the brochure.

What a buyer in this market types

Four query families, and they get progressively more commercial.

Project-name queries. “prestige [project] whitefield”, “[project name] price”, “[project name] floor plan”, “[project name] possession date”, “[project name] review”. These are the highest-intent searches in the entire sector, and the aggregators own them. A buyer searching your own project name should land on your page first, and on most developer sites they do not, because the project page is a JavaScript-rendered slide deck with no text.

Locality queries. “flats in sarjapur road”, “2 bhk in hebbal”, “apartments near electronic city”, “villa projects north bangalore”. High volume, high competition, dominated by portals.

Specification queries. “3 bhk under 1.5 crore bangalore”, “ready to move apartments whitefield”, “plots with khata b”, “east facing flats”.

Diligence queries. “rera number [project]“, “[developer] review”, “[project] construction status”, “khata transfer process bangalore”, “occupancy certificate meaning”. These are the ones nobody builds for, and they are the ones a serious buyer runs before writing a cheque.

The project page, done properly

A project page that competes has text, not just imagery. Specifically: the full project name and the common ways people shorten it, the exact locality and the roads it is accessed from, the RERA registration number as text, unit configurations with carpet areas, the price band, the possession timeline, the amenities as a text list, the approvals obtained, and the current construction stage with a date.

The RERA number matters more than most developers realise. It is searched directly, it is a trust signal, and it is a unique string that no aggregator can claim better than you can. Put it in the body text of the project page and in the structured data.

Construction status updated monthly with a date is the single best reason for a buyer to return to your site rather than a portal. Portals cannot do it. You can, and almost nobody does.

Locality pages that are not portal imitations

Competing with a national portal on “flats in sarjapur road” by writing a worse version of their listings page does not work. What works is a locality page written from the developer's own vantage point: which of your projects are there, what the road is actually like to live on, commute times to the main tech parks, the schools and hospitals people ask about, how prices in that micro-market have moved, and what is under construction nearby that will change it.

That is information a portal aggregating listings does not have and a developer who has built there does. It is also the kind of page that earns links from local publications, which the listings imitation never will.

The diligence content nobody writes

Khata A versus B. What an occupancy certificate means and what to check. How RERA complaints work in Karnataka. What a possession-linked payment plan commits you to. Stamp duty and registration charges on a Bangalore purchase, with current rates.

These pages rank quickly because they are genuinely thin on the ground, they bring in buyers at exactly the moment they are deciding, and they build the kind of credibility that a brochure cannot. They also feed internal links into the project pages naturally.

Technical realities

Most developer sites are built by agencies optimising for the visual, which means text inside images, content loaded over JavaScript after interaction, and PDFs for floor plans and price sheets. Check what a crawler sees. If the project name, the RERA number and the configurations are not in the HTML, the page cannot rank for them no matter how good it looks.

Also: do not retire a project page when the project sells out. Redirect it to a relevant live project or keep it as a completed-project page. Deleting it throws away years of accumulated signals and every external link pointing at it.

Sequencing

Project pages first, with full text and RERA numbers. Construction updates monthly. Four diligence pages. Locality pages last, and only for the micro-markets you actually build in.

If you want that build-order worked out against your own project mix and the search demand around it, that is the kind of plan I put together as an SEO consultant in Bangalore.

A related piece on the same architecture question in a different city: real estate SEO in Mumbai, why project pages beat locality pages.

Every few months a business owner forwards me a PDF from a tool or an agency. Forty pages, a scary number of “toxic” links, a red gauge, and a recommendation to buy a cleanup package. Almost none of these reports describe a real problem, and acting on them is usually worse than ignoring them.

Here is how to read one properly.

“Toxic score” is a vendor invention

No search engine publishes a toxicity metric. Every toxic-score column you have ever seen is a third-party tool's own model, usually built from a mix of signals like TLD, outbound link count, anchor repetition and whether the domain looks like a network. Those signals correlate loosely with low quality. They are not Google's assessment, and the tool has a commercial interest in the number being high enough to justify a subscription.

Treat the score as a sorting aid for your own review. Never as a verdict.

Most low-quality links are already being ignored

This is the part that disarms most of these reports. Google has spent fifteen years getting better at discounting links it does not trust, and since the 2012-era penalty wave the default handling of obvious junk has shifted from punishment to indifference. A scraper site, an auto-generated directory, a hacked blog footer — these overwhelmingly contribute nothing rather than costing you something.

A link that contributes nothing does not need removing. Removing it changes your rankings by zero and costs you a fortnight of outreach emails.

What an actual link problem looks like

There are real cases. They have specific signatures, and a report that does not show these signatures is not describing one.

A manual action in Search Console. Open Security and Manual Actions. If there is nothing there, you do not have a link penalty. This single check invalidates most of the PDFs in circulation.

A sharp, dated drop that matches a link event. Not a slow decline — a step down, on a date, that lines up with either a Google update or a batch of links appearing. Slow declines are almost always content, competition or technical.

Anchor text that is visibly manipulated. If forty percent of your inbound anchors are the same commercial phrase, that is a pattern worth fixing. Normal link profiles are dominated by brand names and URLs, with commercial anchors as a minority. Check the distribution, not the toxic column.

Links you or a previous agency paid for. This is the only category where you have genuine exposure, because you know they were bought and so, eventually, might Google. If a past engagement produced a thousand links in three months, that is worth examining regardless of what any score says.

The disavow file is a last resort, not a maintenance task

Disavowing is irreversible in practice and easy to get wrong. Disavow a domain that was actually helping you and you have removed value with no way to measure what you lost.

The honest guidance, which Google's own search advocates have repeated for years, is that the overwhelming majority of sites never need a disavow file. The exceptions are sites with a manual action, and sites that know they have a history of bought links and are cleaning up deliberately.

If you have neither, the correct action on a toxic-link report is to read it, note anything genuinely odd, and do nothing.

What to do with the report instead

There is useful information in these files, just not the part being sold. Use it for:

• Anchor distribution. Is your profile brand-heavy and natural-looking, or is it stacked with one commercial phrase?
• Target distribution. Are links spread across your service pages, or all pointing at the homepage? Homepage-only profiles are a common and fixable weakness.
• Referring domain growth. Flat for two years is a real signal. Spiky is worth explaining.
• Competitor comparison. The genuinely actionable number is usually how many referring domains your top three competitors have on the specific page that outranks you.

That last one turns a defensive report into a plan.

The one-line version

Check Search Console for a manual action. If there is none, no link report has found a penalty, because a penalty is a thing Google tells you about. Spend the budget on links you want rather than on removing links that were already being ignored.

Earlier in this series: an SEO audit is not an SEO strategy, which is the same category of mistake one level up.

If you have been handed one of these reports and want a second opinion before authorising a cleanup retainer, Deep Bhardwaj can read it against your Search Console history in an afternoon and tell you whether there is anything in it worth acting on.

A canonical tag is one line of HTML and it decides which of your URLs Google treats as the real one. Get it wrong and you can take a page that ranks and make it invisible, without breaking anything a visitor would notice. No error, no 404, no drop in traffic you can trace to a deploy — just a page that stops appearing.

I have found all five of the following on live Indian websites this year. They are not exotic. Three of them were on sites that had been paying for SEO for over a year.

1. The canonical points at the old URL after a migration

This is the most expensive one. A site moves from /service-page.html to /service-page/, the redirects are set up correctly, and the canonical tag in the new page's head still says .html. The redirect tells Google to go to the new URL; the canonical on the new URL tells Google the real page is the old one. The two instructions conflict and the page's ranking signals end up in limbo.

It is invisible in every normal check. The page loads, the redirect works, the content is right. You only see it by viewing source on the live page and reading the canonical, which is a step almost nobody does after a migration sign-off.

2. Every page canonicalised to the homepage

Usually a template or plugin misconfiguration. Someone sets the canonical in a shared header and hardcodes the site root. The result is that every page on the site tells Google “I am actually the homepage”, and the site collapses to one indexed URL. This one is dramatic enough that it gets caught — but typically weeks later, after someone asks why forty pages disappeared from Search Console.

3. Self-canonical on paginated and filtered URLs

Category page two canonicalising to itself, filter combinations canonicalising to themselves, sort orders canonicalising to themselves. The index fills with near-duplicates, crawl budget drains into permutations, and the page you wanted to rank competes with forty variants of itself. On Indian ecommerce sites with faceted navigation this is routinely the largest single indexing problem, and it is usually invisible until someone counts indexed URLs against actual pages.

4. Canonical in the body instead of the head

A canonical tag placed below the opening <body> tag — often by a tag manager or an injected script — is ignored entirely. The page behaves as if it has no canonical at all. Everything looks correct in the source if you search for the string; it is only wrong because of where it sits. Check the position, not just the presence.

5. Mixed protocol and host variants

http:// canonicalising to https://, or www to non-www, inconsistently across the site. Some pages point one way, some the other, often because the site was built across two eras. Google resolves it eventually, badly, and the consolidation of link signals that a canonical exists to achieve never happens.

How to check in ten minutes

Pull your sitemap. Fetch every URL in it. Extract the canonical from each and compare it to the URL you fetched. Any row where they differ is either a deliberate decision you should be able to explain in one sentence, or a bug.

That is it. It is a short script or a crawler run, it takes minutes, and on most Indian sites that have been through a redesign it finds something. On one site earlier this year it found eleven pages canonicalising to URLs that had been retired two years earlier — which is exactly the kind of fault that makes a site feel stuck for reasons nobody can name.

Why this matters more than it sounds

Canonicals are not a ranking factor you optimise. They are plumbing. When plumbing is wrong, every other investment leaks: the links you built point at a page Google has been told is not canonical, the content you wrote sits on a URL that is not the one being indexed, and the audit that found neither looked at rankings rather than at source.

This is the first thing Deep Bhardwaj checks on any Indian site that has been through a redesign or a replatform, because it is quick, it is binary, and it is the fault most likely to be silently undoing everything else.

Related: sitemap hygiene and the 404 trap is the companion check — a sitemap full of URLs that redirect or 404 undermines the same consolidation, and the two faults usually travel together.

Most content briefs in local SEO are written from a keyword tool and nothing else. Volume, difficulty, a target page, go. That skips the only step that tells you whether the page you are about to write can win at all: looking at what is currently ranking and asking what kind of page Google has decided the query deserves.

For Mumbai queries specifically, this matters more than in most markets, because the results are a mix of four very different page types and each one demands a different response.

The four things you will see on a Mumbai commercial SERP

The local pack. Three Google Business Profiles above everything else. If the pack occupies the top of the page, your website is competing for what is left, and the highest-leverage work is on the profile rather than the page. No amount of on-page optimisation moves you into the pack.

Aggregators and directories. Justdial, Sulekha, IndiaMART, a category-specific marketplace. These rank because they publish a filterable list and have domain authority you will not match this year. You do not beat them with a better version of a list. You beat them by being the specific answer their list only points at — which means a page with first-hand detail no aggregator can generate.

Editorial and listicle content. “Top 10 X in Mumbai”, usually on a blog or a media site. When these dominate, the query is being read as informational even though it looks commercial, and a hard sales page will not rank. You need a page that genuinely informs and converts secondarily.

Actual competitors. Other businesses like yours. This is the only one of the four where a like-for-like page can win, and it is worth counting how many of the ten results belong to this category before committing to the page.

The count that decides your strategy

Open the SERP in an incognito window, set to Mumbai, on mobile. Count how many of the visible results are competitors like you.

If it is five or more, a strong service page is a reasonable bet and ordinary on-page work plus links will move you.

If it is one or two, the query is structurally owned by aggregators or the local pack, and a service page is close to unwinnable in the short term. Your effort belongs on the Business Profile, on getting listed well inside those aggregators, and on the longer-tail variants where competitors do appear.

That single count saves more wasted content budget than any other check available, and it takes ninety seconds.

What to read on the pages that do rank

Not their keyword density. Read what they actually contain that yours does not:

• Do they publish prices? If three of the top five do, a page without pricing is at a disadvantage that no title tag fixes.
• Do they show locality-specific proof — projects, clients, photographs from that area?
• How long are they, and more usefully, how many distinct questions do they answer?
• Do they carry reviews or testimonials on the page itself?
• What is the format — a long single page, a page with a form above the fold, a page with a comparison table?

The pattern across the ranking pages is Google telling you what it has learned satisfies this query. Arguing with that pattern is expensive.

The variants worth checking at the same time

While you are looking, run the obvious variants. In Mumbai the pattern is consistent: expert, consultant, services, company, agency, freelancer return noticeably different SERPs for the same underlying need. Consultant and freelancer queries tend to show fewer aggregators and more individual practitioners, which makes them the easier entry point even when their volume is lower.

Neighbourhood variants behave the same way. Andheri, Bandra, Lower Parel, Thane and Navi Mumbai each have their own competitive shape, and the citywide query is almost always the hardest of the set.

Then write the brief

A brief written after this exercise looks different. It specifies page type, not just keyword. It lists the three things competitors publish that you must match. It names the variant you are actually going after first. And sometimes it concludes that the page should not be written at all this quarter, which is a perfectly good outcome.

The wider point about why consultant queries behave differently from company queries is covered at https://indiaseofieldnotes.mataroa.blog/blog/why-seo-consultant-searches-convert-better-than-seo-company-and-what-it-means-for-your-pages/ and is worth reading alongside this.

For Mumbai-specific SERP assessment against your own target list, Deep Bhardwaj does this as a standing part of every engagement rather than as a one-off audit deliverable.

There is a particular kind of website that almost every industrial manufacturer in the Delhi NCR belt has: a homepage with a rotating banner, an “About Us”, a “Products” page listing twenty product families as a grid of images, and a contact form. It has existed for eight years, it ranks for the company name, and it produces no enquiries. The instinct is to add a blog. The correct first step is to build a query map.

What a query map is

A query map is a table with two columns: every commercially relevant search a buyer might type, and the single page on your site that should own it. That is all. It takes a few hours and it is the document that makes every subsequent decision obvious.

The reason it matters for manufacturers specifically is that industrial search vocabulary and marketing vocabulary diverge sharply. Your catalogue says “material handling solutions”. Buyers search “hydraulic scissor lift table 1000 kg”, “belt conveyor manufacturer in faridabad”, “chain pulley block price”. If no page on your site uses the buyer's words, no amount of blogging will help.

How to build it without tools

You can get eighty percent of the way with three inputs and no subscription:

• Your own sales enquiries. Read the last hundred. The phrases customers use in emails and on calls are the phrases they type. This is the highest-quality keyword source you own and almost nobody mines it.
• Search Console, if the site has any history. The Queries report will already show terms you rank for at position 30 to 80 — those are pages half-built, and they are the cheapest wins available.
• Google's own autocomplete and “People also ask” for your five main product families. Type the product name and read what completes.

Sort the result into four buckets: product-specific, product-plus-city, product-plus-specification, and comparison or price queries. Each bucket wants a different page type.

The mapping rules that prevent the usual mess

One page per product family, not one page for all products. A grid of twenty images cannot rank for twenty products. Each family needs its own URL with specifications, capacities, materials, applications and a downloadable datasheet.

One page per specification cluster only where the volume justifies it. “Scissor lift table” is a page. “Scissor lift table 500 kg” is a section on that page, unless the search volume is genuinely separate.

City queries go on city pages, never the homepage. “Conveyor manufacturer in faridabad” should land on a page that talks about Faridabad — the plant, the delivery radius, the local installations. Pointing city queries at the homepage is the single most common wasted opportunity in NCR industrial SEO.

Price and comparison queries get honest pages. Buyers search price constantly and manufacturers refuse to publish it. A page that gives a realistic range with the variables that move it will outrank and out-convert every “contact for quotation” competitor.

What the map tells you to do next

Once the table exists, the work is no longer a matter of opinion. Every row with no page is a page to build. Every row with two candidate pages is a cannibalisation problem to resolve. Every row with a page at position 11 to 25 is a page to strengthen, which is almost always faster than building a new one. And every row with a page at position 1 to 5 is finished — stop touching it.

Manufacturers who build the map first tend to ship fifteen useful pages in a quarter. Manufacturers who skip it tend to ship thirty blog posts and see nothing.

If you want a second opinion on a query map for an NCR industrial site, that is the kind of groundwork Deep Bhardwaj starts every engagement with.

Related: crawl budget for large Indian websites.

Voice search advice aimed at Indian businesses has been recycled from American blog posts for about eight years. Write conversationally. Target question keywords. Optimise for featured snippets. None of it is wrong and almost none of it addresses what is actually different about spoken search in India, which is that a large share of it is not in one language.

What the queries look like

A spoken query in Mumbai or Delhi frequently arrives as a mix: Hindi grammar with English nouns, or Marathi with English brand names, transcribed by Google into Latin script. “sabse accha dentist near me”, “AC repair wala kaha milega”, “mera phone ka screen repair Andheri”. These are not edge cases; in categories like repair services, tuition, healthcare and food they are a meaningful share of mobile queries.

They behave differently from typed queries in three ways worth planning around. They are longer, usually seven to twelve words against three or four. They almost always carry location intent even without a place name, because the device supplies it. And they are overwhelmingly single-answer queries — the person is not comparing eight options, they are asking for one.

What is worth doing

Get the Business Profile right before touching the website. Spoken local queries resolve to the map pack far more often than to organic results, and the map pack is decided by proximity, prominence and category. A correct primary category, real opening hours, the service list populated, and a steady flow of reviews will do more for voice visibility than any on-page change. This is unglamorous and it is where the return is.

Write the FAQ section in the language of the question, not the industry. A dental clinic's page should answer “how much does a root canal cost in Mumbai” in those words, not “our endodontic treatment pricing”. Spoken queries use consumer vocabulary. Most Indian service sites are written in trade vocabulary, and the gap between the two is where the traffic leaks.

Do not try to write in transliterated Hinglish. This is the tempting mistake. Pages written in “sabse accha” style read as spam to users, and Google's language handling is good enough that a clean English page answering the same intent will usually win the query anyway. What matters is the intent match, not the script.

Answer in the first two sentences. Voice assistants that read a result aloud take a short extract. A page that opens with three paragraphs of company history before answering the question does not get read out. Put the direct answer first, then the detail.

Fix speed on real mobile networks. Voice queries skew heavily to mid-range Android on variable connections. A page that takes six seconds on 4G in a Mumbai suburb has lost regardless of its relevance.

What is not worth doing

Schema markup specifically for voice. FAQPage and LocalBusiness are worth having for their own reasons, but there is no voice-specific markup and no evidence of a voice ranking bonus from it.

Chasing “near me” as a keyword. You cannot optimise for the phrase; you optimise for being genuinely near, which is a Business Profile and citation problem.

Long-tail question keyword research at scale. The tools have poor coverage of Indian spoken queries and the volumes they report are unreliable. Search Console's own query data on your existing traffic is a better source, and it is free.

The measurement problem

There is no way to isolate voice traffic. Google does not report input method in Search Console, and every tool claiming to measure voice share is estimating. What you can do is watch the shape of your incoming queries — filter Search Console for queries over six words, and for queries containing question words, and track that segment's impressions over time. It is a proxy, but it moves in the right direction when the work is right.

The honest summary is that optimising for voice in India is mostly just doing local SEO properly, plus writing in the words customers use rather than the words your industry uses. The categories where it matters most are the ones with urgent, single-answer intent — repair, medical, food, emergency services.

For Mumbai businesses in those categories, the local pack work usually matters more than anything on the site itself: https://deepbhardwaj.com/seo-expert-in-mumbai/

Related reading on why redesigns so often break local pack visibility: https://indiaseofieldnotes.mataroa.blog/blog/why-mumbai-businesses-lose-local-pack-visibility-after-a-website-redesign/

Every CMS migration I have been called in to rescue had the same story: the new site looked better, launched on time, and lost thirty to sixty percent of organic traffic within three weeks. Nobody on the project had done anything obviously wrong. The loss came from four or five things that are invisible until traffic drops, and all of them are cheaper to prevent than to fix.

This is the list I work through before any Indian B2B site changes platform.

Freeze the URL structure, or map every single change

The safest migration keeps URLs identical. If the new platform forces a change – and platforms often do, adding or dropping a trailing slash, moving /products/x to /product/x, replacing IDs with slugs – then every old URL needs a one-hop 301 to its true equivalent. Not to the homepage, not to the category, to the equivalent page.

Build that map as a spreadsheet from a crawl of the live site before launch. Include every URL that has a backlink or has received a single organic visit in the last twelve months. On a B2B site this is usually a few hundred rows, which is a day of work, and it is the single highest-return day in the whole project.

The staging robots.txt is the classic own goal

Staging sites are blocked from crawling, correctly. Then the staging build is promoted to production and the block comes with it. The site goes live, looks perfect, and is invisible. I have seen this survive a week because everyone was checking the design rather than the file.

Check yoursite.com/robots.txt in a browser within five minutes of going live. Not later.

Content that quietly did not come across

Migrations lose content in undramatic ways. A field that existed in the old CMS has no equivalent in the new one, so the specification table on every product page silently becomes empty. FAQ blocks that were custom-coded do not survive a theme change. Long descriptions get truncated to a character limit the new platform enforces.

Spot-check your ten most valuable pages against an archived copy, word for word. On a B2B site the missing content is almost always the technical detail – which is exactly the content that was earning the long-tail traffic.

Metadata and schema get rebuilt from templates

New platforms generate title tags and meta descriptions from a template. That template is generic, and it will happily overwrite the hand-written titles that took somebody a month. Export your existing titles and descriptions before migration and re-import them after. The same applies to structured data: if the old site had Organization, Product or FAQ schema and the new theme does not, you have removed it without deciding to.

Internal linking collapses in the rebuild

In-body contextual links are usually the first casualty of a content migration, because the copy gets pasted in as plain text. A B2B site with a well-built internal linking structure can come out the other side with almost none, and the pages that depended on it lose their support. Check a sample of body copy for live links, not just for text.

Launch-week monitoring, not launch-week celebration

For the first fourteen days after go-live: watch Search Console coverage daily for a spike in 404s and in “Crawled – currently not indexed”, submit the new sitemap and confirm it processes, watch server logs or the crawl stats report to see that Googlebot is finding the new URLs, and keep the old analytics comparison open so a drop is visible on day two rather than week four.

Most migration damage is fully recoverable if it is caught in the first fortnight. The expensive cases are the ones discovered a quarter later, by which point the old URLs have been de-indexed and the links pointing at them have stopped passing anything.

What to do if you are already past launch and down

Do not start rewriting content. Crawl the old sitemap, find everything that now 404s or redirects to the wrong place, fix the redirect map, restore the missing on-page content and metadata, and give it three to four weeks. In most cases the recovery is close to complete, because the rankings were not lost on merit.

Deep Bhardwaj has walked several Indian B2B sites through this both before and after launch; the pre-launch version costs a fraction of the post-launch one. Details at https://deepbhardwaj.com/seo-expert-in-india/.

Related reading: Mumbai manufacturers and exporters: turning a product catalogue into pages that rank covers the catalogue content that migrations most often drop.

Most SEO decisions on large Indian ecommerce sites are made on assumptions about crawling. The team believes Googlebot is reaching the category pages, believes the parameter URLs are being ignored, believes the new collection launched last month has been discovered. Log files turn all of that from belief into fact, and the facts are usually unpleasant.

A server log records every request: which user agent, which URL, what status code, when. Filter it to verified Googlebot and you have an exact record of where your crawl budget went.

What the first look usually shows

Three findings come up again and again on Indian catalogue sites.

Most of the budget is going to URLs you do not want indexed. Faceted filters, sort parameters, session IDs, pagination beyond page three, internal search results. It is common to find 60-75% of Googlebot's requests landing on parameter combinations, while the actual category pages get crawled once a fortnight. Every one of those wasted requests is a request not spent on a product page.

Deep products are effectively invisible. Group the crawl data by click depth from the homepage. On a typical large catalogue, pages at depth two get crawled weekly; pages at depth five get crawled every few months, if at all. If a product sits four clicks deep and the logs show no Googlebot hit in ninety days, it is not underperforming – it has not been looked at.

Response codes tell a story nobody was tracking. A steady trickle of 5xx errors during peak traffic hours, redirect chains three and four hops long left over from a migration, and a set of 404s that are still being crawled months after the URLs were removed because something still links to them.

How to run it

Get thirty days of raw access logs from the server or CDN. Verify Googlebot properly by reverse DNS – a meaningful share of traffic claiming to be Googlebot is not. Then join the log data against a crawl of the site so every URL carries its depth, its status, its template type and whether it appears in the sitemap.

Four questions to answer first. What percentage of crawl requests hit indexable pages versus parameters and junk? What is the crawl frequency by template – homepage, category, product, blog? Which indexable URLs received zero Googlebot requests in the period? And which non-indexable URLs received the most?

That last query, sorted descending, is your fix list. It is usually short and the top five entries usually account for most of the waste.

The fixes, in the order they pay

Block the parameter patterns that produce no unique content in robots.txt – and block the pattern, not the individual URLs, because the combinatorics are endless. Set canonical tags on filtered views pointing to the clean category URL, then check the logs a fortnight later to confirm the crawl actually moved.

Flatten the depth of anything that matters. A product four clicks from the homepage should be reachable in two, which usually means better category cross-linking and genuinely useful hub pages rather than a bigger footer menu.

Collapse redirect chains to single hops. Every extra hop is a wasted request and a small loss of signal.

Fix the 5xx errors. Nothing suppresses crawl rate faster than a server that intermittently fails – Googlebot backs off, and it does not come back quickly.

Then measure it again

The point of log analysis is that it is repeatable. Run it again after six weeks and compare the same four numbers. The percentage of requests hitting indexable pages should be up. The zero-crawl list should be shorter. If neither moved, the fix did not take, and you know that in six weeks rather than in a year.

This is also the diagnostic that explains most cases of “we published it and Google ignored it”. Usually Google did not ignore it. Google never reached it.

Teams that want the log pull, the crawl join and the fix list produced as one piece of work can get it done by Deep Bhardwaj, who will normally ask for the CDN logs before anything else. The indexing problems on a large catalogue are almost always upstream of the content.

Indian manufacturers selling into export markets have a content problem that looks like a translation problem and isn't. The catalogue is accurate, the specifications are complete, the certifications are real — and the pages do not rank, because they are written for someone who already knows the product category.

An engineer in Rotterdam searching for a component does not search the way your sales team describes it internally.

The vocabulary gap

Three vocabularies exist for every industrial product: what your factory calls it, what your Indian customers call it, and what the overseas buyer types into Google. Most export sites are written entirely in the first.

Find the third by looking at where buyers already are. Read the titles of competitor listings on the marketplaces your category uses. Read the RFQ language in the enquiries you already receive — those are real buyers using real words, and they are sitting unread in your sales inbox. Read the technical standards your product is certified against, because buyers frequently search by standard rather than by product name.

Then build pages around the buyer's term with your term as a secondary mention, not the reverse.

Units, standards and the regionalisation that actually matters

Localisation for industrial export is not about language. It is about:

• Units in both systems. A page giving dimensions only in millimetres loses the US market; only in inches loses everyone else. Give both, in the same table.
• The standard the buyer's procurement process requires. DIN, ASTM, ISO, BS — naming the standard your product meets, explicitly, on the product page, captures a whole class of high-intent search that generic product pages never see.
• Tolerances and material grades spelled out. “High quality steel” is not a specification. “EN 10025 S355JR” is, and it is searchable.
• MOQ, lead time and packaging. These decide whether a buyer enquires. Omitting them does not create a conversation; it creates a bounce.

Page structure for a product that has variants

The pattern that works for exporters with wide catalogues:

1. A category page that explains the product class, the selection criteria, and the standards it spans — this is the page that ranks for the head term
2. Product pages per genuinely distinct product, with full specification tables
3. A single well-maintained specification or grade comparison page that every product page links to — this tends to attract links naturally, because it is the reference page buyers bookmark
4. Application pages by industry, where the same product sold to two industries is genuinely used differently

Avoid generating a page per size variant. A hundred pages differing only in a numeric field is thin content by any definition, and the search demand for individual sizes is negligible compared with the demand for the class.

Trust signals a foreign buyer looks for

An overseas buyer taking a first-time risk on an Indian supplier is looking for evidence of continuity and compliance. Put it where it is visible: years in operation, factory photographs (not stock images), audit certifications with numbers, export markets already served, named contacts with direct lines, and a physical address that resolves on a map.

Certification logos without numbers read as decoration. Certification numbers read as verifiable, and increasingly the assistants buyers use to shortlist suppliers extract exactly that kind of specific, checkable detail.

Measuring the right thing

Export SEO traffic volume is a poor metric because the total addressable search volume in a niche industrial category may be a few hundred a month. Enquiry quality is the metric — count qualified RFQs, and track which pages produced them. A page delivering four serious enquiries a month is worth more than a blog post delivering four thousand sessions.

Manufacturers who want their catalogue structured against real buyer search language can get that mapping from an SEO consultant in Bangalore: https://deepbhardwaj.com/seo-expert-in-bangalore/

Related reading: https://indiaseofieldnotes.mataroa.blog/blog/keyword-cannibalisation-in-indian-service-sites-how-to-find-it-in-20-minutes/

There is a shift that has been underway for years and became impossible to ignore in 2026: search engines increasingly rank entities, not pages. A page is a document. An entity is a thing in the world that the engine believes exists, with properties it can verify against multiple independent sources.

For an Indian service business, that distinction now decides whether you show up in AI-generated answers at all.

What an entity actually is

When Google encounters “Deep Bhardwaj” it is trying to resolve a string into a node: a person, with a profession, a location, an employer or business, a set of works, and a set of corroborating references. If it can resolve that node confidently, it can cite you. If the string stays ambiguous, you remain a page that might be relevant, competing on keywords alone.

The same applies to a company. “Sharma Consulting, Pune” is a string. An entity is that name plus an address, a phone number, a category, a founding date, a set of services, and twenty places on the web that say the same thing.

Consistency is the whole game

This is unglamorous and most businesses get it wrong.

Pick one canonical form of your name. Not “Deep Bhardwaj”, “Deepak Bhardwaj”, and “DB SEO” across three profiles. One.

Pick one service description. Write it once, in one sentence, and paste that exact sentence into every directory, every author bio, every profile. Not a reworded version each time — the same sentence.

Pick one city. If you are based in New Delhi and serve Mumbai and Bangalore, your entity location is New Delhi, and the other cities are things you serve, expressed as service areas. Claiming three home cities makes all three weaker.

Pick one canonical URL and use it as the website field everywhere.

Where the corroboration comes from

In rough order of how much weight each one carries:

• Your own site, with Person or Organization structured data and a complete sameAs array
• A Google Business Profile, fully filled, matching exactly
• Professional profiles: LinkedIn, Crunchbase where relevant, industry association listings
• Author bylines on publications other than your own, with a consistent bio
• Directory and citation listings, consistent in every field
• Mentions in content you did not write — the hardest to get and the most valuable

The first four are entirely within your control and most businesses have not completed them.

What this changes practically

Two consequences worth planning around.

First, AI answer engines lean heavily on entity confidence. When a model assembles an answer about SEO consultants in India, it is drawing on entities it can resolve, not on whichever page has the best title tag. Being resolvable is the entry ticket.

Second, entity strength transfers across queries. A page-level optimisation helps that page. A stronger entity lifts everything associated with it, including new pages published later.

The work, in order

Week one: audit every place your name appears online and list every inconsistency. There will be more than you expect.

Week two: fix the ones you control. Standardise name, description, city, URL, phone.

Week three: add or correct structured data on your own site, with sameAs pointing at every corrected profile.

Week four onward: add new corroborating references at a steady pace. Profiles, bylines, listings, citations. Consistently, in the same form, forever.

It is not complicated work. It is work that rewards discipline over cleverness, which is why so few businesses finish it — and why finishing it is still a competitive advantage in 2026.

I write about this and the rest of the technical side regularly; my own approach is documented by Deep Bhardwaj.

Related: Schema markup for Indian service businesses