Localization SEO spans two distinct disciplines. International SEO makes your content discoverable across countries and languages by pairing market-specific content with hreflang tags and localized URL structures. Local SEO makes your business visible in geographically relevant results, especially Google Maps and the Local Pack for location-aware queries such as "near me" searches. Both require adapting your content and technical setup to how people actually search in a specific market. Mixing the two can blur ownership and implementation scope.
Google's current local ranking documentation centers local visibility on prominence as well as relevance and distance, while international SEO documentation emphasizes locale-specific URLs and hreflang annotations.
- Localization SEO adapts your search strategy to match how people search in specific languages and regions
- Hreflang tags and localized URL structures support international SEO, while schema markup supports location pages
- Local SEO requires consistent NAP citations plus ongoing Google Business Profile work for locations and reviews
- A headless CMS (Content Management System) with built-in internationalization (i18n) support (like Strapi 5) can simplify the technical implementation
What is localization SEO?
Localization SEO is the practice of improving your website and content for search visibility in geographic language markets. Keep its two dimensions separate.
International SEO targets users in different countries and languages. Google Search Central distinguishes a multilingual website ("any website that offers content in more than one language") from a multi-regional one ("one that explicitly targets users in different countries"). Hreflang annotations and localized content pair with URL structures such as country code top-level domains (ccTLDs) or subdirectories. Search Engine Land frames localization as work that goes beyond translation to account for local psychology and regional search behavior.
Local SEO targets users searching for businesses near a physical location. Google states that local results are mainly based on "relevance, distance, and popularity". Google Business Profile and NAP citations carry location data, while LocalBusiness schema gives Google structured detail.
Many teams need both. A restaurant group operating in three countries needs hreflang and localized content per market, plus a verified Business Profile and consistent citations per outlet. Building a content localization strategy up front beats retrofitting one later, and it usually starts with a multilingual content management system that can model locales properly.
International SEO foundations
International SEO depends on hreflang annotations and crawlable locale-specific URLs matching the keyword map built from the market's own search engine results pages (SERPs). If one of those drifts, Google may still crawl the page, but it may not show the right version to the right audience.
Hreflang implementation
Hreflang tags tell Google which language or region version of a page to show a given user. Google supports three implementation methods. HTML <link> tags go in the <head>. For non-HTML files like Portable Document Format (PDF) files, use Hypertext Transfer Protocol (HTTP) Link: headers; Extensible Markup Language (XML) sitemaps can carry <xhtml:link> annotations. Use a consistent method per site so implementation stays auditable.
Google's HTML example uses alternate links in the <head>:
<head>
<title>Widgets, Inc</title>
<link rel="alternate" hreflang="en-gb"
href="https://en-gb.example.com/page.html" />
<link rel="alternate" hreflang="en-us"
href="https://en-us.example.com/page.html" />
<link rel="alternate" hreflang="en"
href="https://en.example.com/page.html" />
<link rel="alternate" hreflang="de"
href="https://de.example.com/page.html" />
<link rel="alternate" hreflang="x-default"
href="https://www.example.com/" />
</head>Apply these checks no matter which method you choose:
- Each language version needs to list itself as well as all other versions, and links need to be bidirectional because per Google, "if two pages don't both point to each other, the tags will be ignored."
- Every URL needs to be absolute and fully qualified (
https://example.com/fooinstead of/foo).
Hreflang is also easy to break during releases when route or canonical settings change, or when locale slugs change, so this is one area where a small regression can quietly affect an entire market. Language codes follow International Organization for Standardization (ISO) 639-1 with an optional ISO 3166-1 Alpha 2 region code, so en-GB is valid while region-only values and reserved codes like UK and EU get ignored. The x-default value designates the fallback page for users whose language matches nothing else, typically a language selector. For how hreflang fits into a broader multilingual strategy, see our guide to multilingual SEO best practices.
URL structure for multilingual sites
You have three options for structuring localized URLs:
| Structure | Example | Trade-off |
|---|---|---|
| Subdirectory | example.com/de/ | Easy setup (multi-regional setup guidance); low maintenance (multi-regional maintenance guidance); weaker geo signal than ccTLDs |
| Subdomain | de.example.com | Easy setup; weaker geo signal than ccTLDs; can separate locale management |
| ccTLD | example.de | Strongest geo signal; separate domain per market; highest maintenance |
Google's URL structure best practices list ccTLDs and country-specific subdirectories as recommended; subdomains don't appear on the recommended list. For most teams, subdirectories win because they keep localized content on one domain while still giving every language or country version its own crawlable URL. Google's multi-regional guidance also notes that ccTLDs provide a strong country signal, but they require a separate domain per market.
Strapi 5 can help you manage subdirectory-based multilingual sites. Its Representational State Transfer (REST) application programming interface (API) accepts a locale query parameter (GET /api/restaurants?locale=fr), so a Next.js front end with locale-prefixed routes like /fr/about passes the matching locale to each API call. Our tutorials on multilanguage Strapi website and multi-language blog tutorial walk through the full pattern. One caveat: hreflang is required regardless of which URL structure you pick.
Localized keyword research
Direct keyword translation almost never works. Search Engine Land explains that search behavior depends on market maturity, device preferences, local competitors, and cultural expression. Its examples make the point concrete: an English campaign targeting "background check" in France needs the locally understood term "casier judiciaire"; the grammatically correct translation "vérification d'antécédents" lacks real search volume. In Italy, the literal translation "prestito auto" misses the local query pattern; users search "finanziamento auto." Regional variants within one language matter too, so build each locale as its own search market with its own research.
A practical workflow starts with native SERPs in each market, then validates with tools. Keyword Planner filters offer location and language filters. Those filters help you build a separate keyword map per locale, and sometimes the right call is to accept that a translation makes no sense and write a new article from local research instead. Our post on Strapi localization best practices covers how to organize that per-locale content.
Local SEO foundations
Local SEO builds location trust for each physical location. Keep each location easy to verify, easy to match across directories, and clear to Google through structured data.
Google Business Profile setup and maintenance
For physical locations, invest in each Google Business Profile. Google states that local results are based mainly on relevance, distance, and prominence, and that prominence can be influenced by information such as links, articles, directories, review count, and review score. You'll usually start by claiming and verifying each profile; Business Profile verification currently offers video, phone/text, email, live video call, and mail verification, with review taking up to five business days. Google's guidelines are explicit for multi-location businesses: create no more than one page per location of your business.
Keep each profile aligned with Google's business details guidance:
- business profile details should match the real-world business. Keep the business name, address, phone number, category, hours, website URL, and location-specific attributes aligned.
- Google says that replying to reviews can build customer trust, and businesses need to verify their profile before replying.
- Updates and photos can help users who land on your profile understand what is current; Business Profile posts can include Updates. Offers and Events are available post types too.
Treat the profile as living location data that needs regular updates.
NAP consistency
Your Name, Address, and Phone number need to be identical across directories. Use the same NAP on your website, Google Business Profile, Yelp, and every directory that lists you. Search Engine Journal explains why: Google uses citations as a trust signal, and "it is difficult for Google to trust business information when there are conflicting signals." Consistent business data gives Google and customers a clearer, less ambiguous record of each location.
A quarterly audit helps. Start with one canonical NAP, compare your site and profile against it, compile existing citations, and fix high-authority directories and data aggregators first, since aggregator errors propagate downstream. This is the kind of drift most teams only notice after a directory update or user edit starts conflicting with the source of truth. Directory changes, user edits, and aggregator updates can all push location data away from the source of truth, so citation management requires ongoing work.
Local schema markup
LocalBusiness structured data helps Google surface your locations in local packs and rich results such as the knowledge panel. Google requires name and address, and recommends geo (coordinates to at least five decimal places), openingHoursSpecification, telephone, url (pointing to the specific location's page), and priceRange. Use the most specific subtype available, such as Restaurant or Electrician; reserve generic LocalBusiness for cases without a more precise fit. A trimmed JavaScript Object Notation for Linked Data (JSON-LD) example based on Google's documentation:
{
"@context": "https://schema.org",
"@type": "Restaurant",
"name": "Dave's Steak House",
"address": {
"@type": "PostalAddress",
"streetAddress": "148 W 51st St",
"addressLocality": "New York",
"addressRegion": "NY",
"postalCode": "10019",
"addressCountry": "US"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 40.761293,
"longitude": -73.982294
},
"url": "https://www.example.com/restaurant-locations/manhattan",
"telephone": "+12122459600",
"priceRange": "$",
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday"],
"opens": "11:30",
"closes": "22:00"
}
]
}It is usually better to leave review and aggregateRating off your own pages; Google only recommends them for sites that capture reviews about other local businesses, and self-serving reviews are ineligible for star rich results. For validation, the Rich Results Test checks Google rich result eligibility, and the Schema Markup Validator checks syntax. The legacy Structured Data Testing Tool that older guides reference was part of a December 2020 migration.
Common localization SEO challenges
Inconsistent NAP citations
Search engines and users need one clear version of each location's name, address, and phone number. Those citation errors recur unless the quarterly audit runs on a schedule; resolve duplicates as they surface.
Duplicate content on location pages
Watch for doorway abuse on location pages. Google's spam policies describe it as doorway abuse, or "creating substantially similar pages that are closer to search results than a clearly defined, browseable hierarchy." Google's duplicate content guidance also states that "some duplicate content on a site is normal and it's not a violation of Google's spam policies." Differentiate each location page with genuinely local material, such as landmark-based directions, location-specific reviews, local team photos, and an embedded map. Strapi's custom fields make it easy to model these per-location attributes in your Content-Types.
Negative review management
Ignoring reviews can weaken customer trust because unanswered criticism becomes part of the public buying experience. Respond constructively, keep new reviews flowing, and make sure every verified location has an owner or manager responsible for review follow-up.
Tools for localization SEO
Google Analytics 4 (GA4)
GA4's predefined dimensions include Country, Region, City, and Language, surfaced in the Demographic details report. Link Search Console to GA4 to get the Google Organic Search Traffic report with Country drilldown; note that Search Console metrics in GA4 are only compatible with the Landing page, Device, and Country dimensions. For per-locale analysis, a Free-form exploration with Country and Landing page as dimensions lets you filter by locale directory (/fr/, /de/) and use engaged sessions and conversion rate by region as the primary metrics. Bounce rate is less useful for that per-locale view.
Google Search Console
The Countries tab in the Performance report shows query and click data per market. One correction for anyone following older guides: the International Targeting report has been deprecated, though Google continues to support hreflang tags. Since the Page indexing report doesn't detect alternate language pages, create a separate URL-prefix property for each locale (such as example.com/de/) to monitor indexing independently.
Strapi 5
Strapi 5 i18n replaces the separate plugin Strapi v4 required. For Strapi 5 implementation:
- You manage locales from Settings > Global Settings > Internationalization in the Admin Panel. Choose from 500+ pre-defined ISO locales, and enable i18n per Content-Type in the Content Types Builder.
- The REST API uses a single
localequery parameter, a breaking change from v4's verboseplugins[i18n][locale]syntax, andlocale=allis no longer supported in v5. - GraphQL gets an equivalent
localeargument, and the Growth plan adds AI-powered translations triggered when default-locale content is saved.
These details matter when you are moving from translated content to a maintainable localization workflow. Strapi implementation resources cover i18n implementation guide, i18n for static sites, React Native tutorial, and tools for multilingual websites.
Where to go from here
Localization SEO makes your content discoverable by the right audience in the right market. Start with the technical foundations: hreflang with self-referencing bidirectional links, a subdirectory URL structure, LocalBusiness schema, and consistent NAP. From there, layer in per-locale keyword research and Google Business Profile optimization where you have physical locations, and measure everything through GA4 explorations and per-locale Search Console properties.
Strapi 5's native Internationalization handles the multilingual content infrastructure, and its locale-parameterized Strapi APIs make serving the right content to each market straightforward. If you want managed hosting, Strapi Cloud is one option.







