DEV Community: Aniruddha Pramanick

Local SEO for Indian SMBs in 2026: the GBP + Local Business schema setup I ship on every client site

Aniruddha Pramanick — Mon, 27 Apr 2026 04:49:11 +0000

I run a small web dev agency in Kolkata. Most of our clients are Indian SMBs — boutique stores, clinics, coaching centres, B2B traders. After 150+ websites, I've noticed one consistent pattern:

Founders care a lot about how the homepage looks. They care almost nothing about whether Google knows where they are.

Then a few weeks after launch I get the same WhatsApp message: "Bhai, search me toh aa hi nahi raha." (Brother, it's not even appearing in search.)

The site is fine. The problem is that nothing on it — and nothing about it — tells Google's local stack what this business actually is, where it operates, or that it's the same entity as the Google Business Profile sitting on Maps.

This post is the technical checklist I now run on every client site to close that gap.

The two-system problem

There are two systems Indian SMBs need to keep in sync:

Google Business Profile (GBP) — the Maps listing, address, hours, photos, reviews. This is what shows up in the local 3-pack and on Google Maps.
The website — where Google's organic crawler reads structured data, sitemap, internal links, and schema.

Local rankings improve when these two systems agree. Most of the suppression I see in client Search Console reports is because they don't.

Part 1: the GBP side (the 5-minute version)

I'll keep this short — the founder-facing setup details are out of scope for a dev post. But before you ship anything for a new SMB client, confirm these:

Profile is claimed and verified. Unverified profiles get almost no Maps visibility. In India, postcard verification still dominates; video verification is now common too. Allow 5–14 days.
Primary category is the most specific accurate option. Not "Business" — "Beauty Salon", "Ayurvedic Clinic", "Web Designer", whatever fits exactly.
NAP is locked. Name, Address, Phone. Decide the canonical version with the client and write it down. This is the string you'll hardcode everywhere.
Hours, photos, description are filled in. Empty sections suppress rankings.

Once that's done, the website work begins.

Part 2: LocalBusiness JSON-LD on every client site

This is the single highest-leverage piece of code I add to Indian SMB sites. Drop it in the <head> of your homepage:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Infinite Option",
  "image": "https://infiniteoption.com/logo.png",
  "@id": "https://infiniteoption.com/#localbusiness",
  "url": "https://infiniteoption.com",
  "telephone": "+91-90516-21062",
  "priceRange": "₹₹",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "G2/A, 94 Shibpur Road, Mandirtala",
    "addressLocality": "Howrah",
    "addressRegion": "WB",
    "postalCode": "711102",
    "addressCountry": "IN"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 22.5747,
    "longitude": 88.3197
  },
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday","Saturday"],
    "opens": "10:00",
    "closes": "19:00"
  }],
  "sameAs": [
    "https://www.facebook.com/infiniteoption",
    "https://www.instagram.com/infiniteoption",
    "https://g.page/infiniteoption"
  ]
}
</script>

A few specifics that matter for India:

"addressCountry": "IN" — set this explicitly. Some boilerplate templates default to "US" and nobody notices for months.
"telephone" in +91 format with hyphens. It must match the GBP exactly, character for character.
"sameAs" should include the actual g.page/... link from the GBP. This is the explicit machine-readable connection between the two systems Google's algorithm needs to see.

For multi-location businesses, use @type: "Organization" at the root with multiple subOrganization entries — one LocalBusiness per location, each with its own @id.

Always validate with the Schema Markup Validator (validator.schema.org) before pushing live. A broken schema is worse than no schema.

NAP consistency at the code level

The mistake I made on early projects was hardcoding the address in three places — the footer, the contact page, the schema — and letting them drift. Six months later the footer said "Mandirtala, Howrah" and the schema said just "Mandirtala". That's a NAP mismatch, and it quietly suppresses local rankings.

Fix: one source of truth in config, rendered everywhere.

For a PHP/MySQL stack (most of my client sites):

// config/business.php
return [
    'name'    => 'Infinite Option',
    'phone'   => '+91-90516-21062',
    'email'   => 'contact@infiniteoption.com',
    'address' => [
        'street'   => 'G2/A, 94 Shibpur Road, Mandirtala',
        'city'     => 'Howrah',
        'region'   => 'WB',
        'postcode' => '711102',
        'country'  => 'IN',
    ],
    'hours' => '10:00–19:00 Mon–Sat',
    'gbp'   => 'https://g.page/infiniteoption',
];

Then require this in the footer partial, the contact page template, and the JSON-LD generator. One edit updates every surface.

For WordPress, ACF Options Page does the same job. For Shopify, theme settings stored in config/settings_data.json. For Next.js, a single siteConfig.ts exported from /lib.

The principle is the same regardless of stack: the address string lives in exactly one place in the codebase.

The footer + contact page

Your footer should render the same NAP triple that's in the schema — visibly, in plain text, crawlable. Not baked into an image, not painted in by JavaScript after first paint. Static HTML.

Same for the contact page. Plus an embedded Google Map iframe pointing to the actual GBP pin. Grab the embed URL from inside the GBP dashboard itself, not by manually searching the address on Maps.

<iframe
  src="https://www.google.com/maps/embed?pb=..."
  width="100%" height="320"
  loading="lazy"
  referrerpolicy="no-referrer-when-downgrade"
  title="Our location on Google Maps">
</iframe>

This iframe is a small but real signal that the website and the GBP are the same entity.

Sitemap + Search Console

Last step every time:

Generate sitemap.xml — your CMS probably already does, but verify it includes the homepage, contact page, services, and any location pages.
Submit it via Google Search Console.
Verify domain ownership in GSC using a DNS TXT record. More reliable than the HTML file method for clients on Hostinger/GoDaddy where file uploads sometimes get clobbered by deployments.
In GSC → Settings → Associations, link the GSC property to the GBP.

That last point matters and is often skipped. Until GSC and GBP are explicitly associated, they behave like two separate islands of data — even if they describe the same business.

The shippable checklist

[ ] GBP claimed and verified
[ ] Canonical NAP locked in a config file (one source of truth)
[ ] LocalBusiness JSON-LD in homepage <head>, validated
[ ] Footer + contact page render the same NAP, crawlable plain text
[ ] Embedded map on contact page points to the actual GBP location
[ ] sitemap.xml submitted in GSC
[ ] GSC ↔ GBP associated

This is the code-side half. The other half — actually setting up and running the GBP, writing the description, collecting reviews, posting weekly updates — is non-dev work the founder has to own. Our content team wrote a fuller walkthrough of that side aimed at Indian business owners: How to Set Up and Optimize Your Google Business Profile in India in 2026. I send it to clients during onboarding so they have a single reference for the parts I can't ship for them.

If anyone has shipped a different schema pattern for Indian multi-location SMBs — especially the Organization + sub Organization setup with separate GBP profiles per branch — drop it in the comments. Always learning here.

Will AI Really Replace Web Developers in 2026? An Indian Agency Owner's Take

Aniruddha Pramanick — Sat, 18 Apr 2026 08:22:42 +0000

Originally published on [Infinite Option]
I run a web development agency in Howrah, India, and wanted to share this with the wider developer community here.

Overview

The question of whether AI will replace web developers has become one of the most urgent conversations in the tech industry in 2026. Every week a new headline declares that AI automation is eliminating jobs and making entire skill sets obsolete overnight. For developers, students considering AI careers, and business owners who rely on web development services — the anxiety is real.

But the honest answer is far more nuanced than any headline suggests. AI is transforming the future of web development — but transformation and replacement are two fundamentally different things. AI is changing what developers spend their time on, not whether developers are needed at all.

What AI Can Actually Do in Web Development Today

GitHub Copilot, developed by Microsoft and OpenAI, is the most widely used AI coding assistant in the world. It suggests code completions, generates entire functions from natural language descriptions, and has become standard in professional web development workflows.

ChatGPT for coding has made debugging, code explanation, and rapid prototyping dramatically more accessible. Paste an error message, get a diagnosis instantly. Generate snippets in multiple languages. Explore implementation approaches without hours of documentation reading.

AI web design tools like Framer AI, Wix ADI, and Adobe Firefly can generate layout suggestions, color schemes, and complete page templates from text prompts. For simple, templated outputs, the speed is remarkable.

The future of programming is clearly one where AI tools handle more of the mechanical, repetitive layers of code. That shift is already happening and it is accelerating.

What AI Cannot Replace — And Why Human Expertise Still Wins

Human creativity in web development is the most fundamental gap. A client with a complex business problem, a unique brand identity, and specific UX requirements needs a developer who can think strategically, ask the right questions, challenge assumptions, and design solutions that no prompt can fully specify. AI in 2026 consistently struggles with the why, not the how.

AI is excellent at pattern recognition within existing data — but building something genuinely new, solving an unprecedented problem, or designing a system architecture that balances ten competing business requirements is still deeply human work. AI also cannot manage client relationships, navigate ambiguous requirements, or take accountability for delivery — all core to professional web development services.

The future isn't AI building websites autonomously. It's developers who use AI tools effectively being dramatically more productive than those who don't.

AI Taking Over Jobs — Separating Fear From Fact

Jobs actually replaced by AI in tech so far have overwhelmingly been narrow, highly repetitive roles — data labelling, basic QA, template-based content generation.

In web development specifically, AI is replacing specific tasks — not the developer's role as a whole. Most vulnerable: writing boilerplate, generating placeholder content, producing basic CSS layouts, converting design files into standard templates. These were always the least valuable parts of the work.

What AI is not replacing: complex problem-solving, architectural decision-making, client communication, quality assurance, and creative judgment. Data from 2024 and 2025 consistently shows companies using AI automation are hiring more developers, not fewer — because AI expands what's possible and creates new categories of work faster than it eliminates existing ones.

The AI Engineer — A New Career, Not a Replacement

The most significant new path for anyone considering AI careers is the emergence of the AI engineer as a distinct professional role. An AI engineer isn't a traditional developer who uses AI tools — they build, train, deploy, and maintain AI systems, integrate machine learning pipelines, and create the infrastructure that AI tools run on.

AI engineer roles are among the fastest-growing and highest-paying in tech globally and in India specifically. For web developers worried about AI making their skills irrelevant, this path is actually one of the most compelling directions available. A developer with strong web development experience who upskills into AI engineer territory — APIs, model integration, prompt engineering, ML basics — becomes one of the most valuable professionals in the market.

Web Developer Skills 2026 — What You Need to Stay Relevant

Here's what matters most right now:

Prompt engineering — knowing how to instruct Copilot, ChatGPT, and other AI tools to produce production-ready output
AI tools integration — embedding AI web design tools, ML models, and intelligent APIs into projects
System architecture and problem solving — AI handles mechanical layers; humans handle structural ones
Client and business communication — relationship management becomes more valuable as AI handles execution
Continuous learning — skills in 2028 will look different from 2026; curiosity is the moat

What This Means for Businesses Using Web Development Services

AI web design tools and GitHub Copilot make building faster, but they don't replace the judgment, strategy, and quality accountability that professional web development provides. A business using a cheap AI-generated site instead of a proper build is trading short-term savings for long-term performance gaps in speed, SEO, security, and brand credibility.

Conclusion

Will AI replace web developers entirely? No — and the evidence in 2026 makes this clearer than ever. Jobs actually replaced by AI in web development are the narrowest, most repetitive task layers — not the creative, strategic, and relationship-driven work that defines the profession.

The AI engineer is one of the most exciting new career paths precisely because it builds on web development expertise rather than replacing it. The future belongs to developers who embrace AI as a tool, businesses that invest in quality builds with intelligence baked in, and professionals who see careers in AI as an evolution of the craft they already love.

I've written the full, longer version with more data and examples on our blog — [read it here].

What's your take — are AI tools making you faster, or are you worried about the long-term direction? Would love to hear from other devs in the comments.