Setting Up International Targeting for a .in Domain

Setting up international targeting for a .in domain means telling Google, explicitly, which pages serve which country, because a .in domain by itself signals India and nothing else. Google’s own documentation lists ccTLDs (country-code domains like .in) as a strong geotargeting signal on their own, so a .in site that wants to also rank for buyers in the US, UK, or UAE needs hreflang annotations, the right URL structure (usually subdirectories such as yoursite.in/us/), and supporting signals like currency and local backlinks to override that default. One thing has changed recently and trips people up: Google Search Console’s old “International Targeting” report, which let you manually set a country target, was deprecated back in 2022. That manual override doesn’t exist anymore. Everything now runs through hreflang and content signals instead.

Why a .in Domain Needs Extra Work for International Targeting

Google’s documentation on managing multi-regional sites is direct about this: country-code top-level domains “are tied to a specific country” and “provide a strong signal to both users and search engines that your site is explicitly intended for a certain country.” That’s the whole story with .in. Unlike .co, .io, .me, or .tv, which Google’s own reference list treats as generic domains despite looking like ccTLDs, .in is not on that generic list. It reads as India, full stop, unless you actively tell Google otherwise on a page-by-page basis.

This isn’t a penalty. It’s just a default. A .in domain can absolutely rank in the US or the UK; it just needs the explicit signals a .com domain gets more benefit of the doubt on. If you’re still deciding whether to stay on .in or move to a gTLD entirely, that’s a separate decision covered in our comparison of ccTLD versus gTLD options for an Indian business going global. This guide assumes you’re keeping the .in domain and want to add international targeting on top of it.

Worth knowing before you write off .in as a domain choice: it’s not a fringe extension. Registrations passed 4 million as of March 2024, according to the National Internet Exchange of India (NIXI), the body that manages the .in registry, putting it among the top 10 country-code domains worldwide by volume. That scale doesn’t change the geotargeting mechanics described above, but it’s a reasonable answer to anyone on your team asking whether staying on .in while going international is even a sensible path. Plenty of other .in businesses are working through the same problem.

Step 1: Choose a URL Structure for Your International Pages

Google’s guidance lays out three practical options, each with real tradeoffs. There’s a fourth (URL parameters like ?loc=us) that Google explicitly does not recommend, so skip it.

For most small and mid-sized Indian businesses, a subdirectory on the existing .in domain is the sensible starting point. It’s the option with the lowest setup cost and it keeps whatever domain authority you’ve already built in one place, rather than splitting it across two properties that both need their own backlinks and content.

Step 2: Implement hreflang Correctly (This Is Where Most Setups Break)

Once your URL structure exists, hreflang tags are what actually tell Google which page serves which audience. Google supports three equivalent methods: HTML link tags in the page head, HTTP headers (useful for PDFs and non-HTML files), or an XML sitemap with hreflang annotations. Pick one method and use it consistently; mixing all three across a site is harder to maintain and offers no ranking benefit for the extra effort.

• Every page must link to itself as well as every other language/region variant. If your India page lists a US variant, the US page must link back to the India page, or Google ignores the pair.
• Use valid ISO codes: language in ISO 639-1 (en, hi), region in ISO 3166-1 Alpha 2 (US, IN, GB). Codes like “UK” or “EU” aren’t valid region codes and Google ignores that part of the tag if you use them.
• URLs inside hreflang tags must be fully qualified: https://yoursite.in/us/page, never a relative path.
• Add an x-default tag pointing to a generic landing page or country selector for visitors whose language or location doesn’t match any of your explicit variants.

Step 3: Reinforce Hreflang With Non-Technical Signals

Hreflang isn’t the only thing Google looks at. Its documentation lists several supporting signals it weighs alongside the technical tags: server location, local addresses and phone numbers on the page, the use of local currency and language, links from locally relevant sites, and, where applicable, Business Profile signals. None of these alone will fix bad hreflang, but together they reinforce it.

For a .in domain adding a /us/ subdirectory, that means the US pages should show USD pricing, a US-relevant contact option, and content written for US phrasing and intent, not a copy of the India pages with the currency symbol swapped. If your business also operates locally in India and relies on Google Business Profile for local visibility, keep that separate from your international targeting work; we’ve covered Google Business Profile setup for Indian businesses as its own topic because it solves a different problem (local discovery, not cross-border rankings).

What Changed: the Old Country-Target Setting in Search Console Is Gone

Search Console used to have a feature called the International Targeting report, launched in 2014, that let a site owner set a single country target for the whole property with a dropdown. Google announced its deprecation in August 2022 and removed it the following month, according to Google’s own Search Console Help documentation. If you’ve read an older SEO guide that tells you to “just set your target country in Search Console,” that advice is out of date. There’s no manual override anymore. Hreflang, URL structure, and content signals are the whole toolkit now, which makes getting them right at setup time more important, not less.

Common Setup Mistakes on .in Domains Going International

1. Adding hreflang only to the new international pages, not the original India pages. The return-link requirement means both sides need the tags, not just the new subdirectory.
2. Forgetting canonical tags when content overlaps. If your India and US pages are near-duplicates in English, a missing rel=”canonical” alongside hreflang can create confusion about which version Google should index as primary.
3. Relying on IP-based redirects instead of explicit links. Google’s documentation specifically warns against IP-based content adaptation; it’s unreliable and Googlebot mostly crawls from US-based infrastructure anyway, so IP logic won’t even show Google the right version.
4. Assuming a .in domain caps you at Indian traffic forever. It doesn’t. It just needs deliberate work that a .com might get for free.
5. Setting it up once and never checking again. A redesign, a new CMS, or a plugin update can silently break hreflang tags. Nothing in Search Console will flag it loudly since the dedicated report is gone; you have to check manually or with a third-party crawler.

How to Verify Google Is Actually Picking Up Your International Pages

Setup is only half the job. Confirming it worked is the other half, and it’s the step most teams skip because nothing forces you to do it. Start with the URL Inspection tool in Search Console on a handful of your new international pages; it will show you whether the page is indexed and, in the coverage details, whether Google sees it as a duplicate of another page on your site, which is a common symptom of a broken hreflang pair.

A rough manual check: search site:yoursite.in/us/ directly in Google and see what comes back. It won’t tell you about hreflang correctness, but it will tell you whether the subdirectory is indexed at all, which is the more basic problem to rule out first. If pages aren’t indexed after a few weeks, the issue is more likely crawlability or a noindex tag than hreflang, and it’s worth checking robots.txt and your sitemap submission before troubleshooting hreflang pairs.

Once pages are indexed, watch Search Console’s Performance report filtered to queries and pages under the international subdirectory. Early on, expect low impressions; a brand-new subdirectory has no independent history and Google needs to build confidence in it, similar to a new site. Three months is a reasonable point to take a first real look at whether the setup is doing anything, not two weeks.

Is This Worth Doing Yourself or Outsourcing?

The technical setup here is not exotic, but it is easy to get subtly wrong in ways that fail silently, since Google ignores broken hreflang pairs rather than throwing an error anywhere visible to you. A small business running one subdirectory can reasonably do this in-house with a checklist. A business planning to target three or four countries from a single .in domain, each with different currency, language, and content needs, usually benefits from having someone who’s set this up before running point on it. If you want a second set of eyes on your setup, our SEO services page outlines how we scope international technical SEO work separately from ongoing content and link building.

Frequently Asked Questions

Can a .in domain rank well in the US or UK at all?

Yes. A ccTLD is a strong default signal, not a hard restriction. Plenty of .in sites rank internationally once hreflang, URL structure, and content signals like currency and local relevance are set up correctly for the target country.

Do I need a separate Search Console property for each country subdirectory?

Not strictly, but many teams find it easier to verify each subdirectory (yoursite.in/us/, yoursite.in/uk/) as its own property or use URL-prefix properties so performance data doesn’t blend together in one country-agnostic report.

What’s the fastest way to check if my hreflang is actually working?

Use a third-party hreflang testing tool against your live URLs, not just a code review in your CMS. Google’s own documentation recommends this because errors like missing return links or invalid region codes get silently ignored rather than flagged anywhere in Search Console.

Should I use hreflang or just write separate content for each country?

Both, together. Hreflang tells Google which pages are variants of each other; it doesn’t replace the need for genuinely different content, currency, and phrasing on each variant. Using hreflang on identical, untranslated content with only a currency swap is a weak setup at best.

Is it too late to add international targeting to a .in site that’s already indexed?

No. Adding hreflang and a new subdirectory to an existing, indexed .in site is a common and low-risk change. It doesn’t require moving your existing India-facing URLs or resetting your indexing history.