Multilingual SEO: How to build, structure & scale global websites

Multilingual SEO: How to build, structure & scale global websites

If your website is only in English, you’re leaving a large portion of the global market untouched.

Over half of all Google searches happen in languages other than English, yet most businesses treat international expansion as an afterthought—slapping on a translation plugin and hoping for the best.

That approach doesn’t work.

Building a multilingual website that actually ranks requires a deliberate strategy combining technical precision, localised content, and smart information architecture.

In this guide, we’ll walk through everything you need to know about multilingual SEO, from foundational concepts to enterprise-level implementations across 40+ languages.

What is multilingual SEO (and how does it differ from international SEO?)

Multilingual SEO is the practice of optimising a website to rank in search results across multiple languages. It’s not about targeting different countries—it’s about making your website’s content discoverable to users searching in their native language, whether that’s Spanish, German, Japanese, or any of the thousands of languages people use online.

This involves optimising and localising content, user experience, and technical setup for multiple languages simultaneously. A multilingual site might serve English, Spanish, and German speakers all from the same domain, with each language version fully optimised for search engines in that language.

The distinction from international SEO matters. International SEO is country or region-led—think of it as targeting the US market differently from the UK market, even though both speak English. Multilingual SEO is language-led, prioritising the language experience regardless of geographic boundaries.

Consider these examples:

  • Multilingual approach: One .com site serving content in 5 languages (/en/, /es/, /de/, /fr/, /ja/)

  • International approach: Separate English experiences for US (example.com), UK (example.co.uk), and Australia (example.com.au)

At Blu Mint, we apply a language-first model on complex builds.

When we built the Fortivus website in 40 languages, we prioritised language targeting over pure regional targeting because its B2G/B2B offer serves global audiences with little country-level variation.

Why multilingual SEO matters in todays globalised world

English-only websites systematically underperform in non-English markets, even as global search volume continues to grow. Here’s why a multilingual SEO strategy deserves your attention:

  • Over 50% of all Google queries are conducted in languages other than English, representing billions of daily searches that monolingual sites simply cannot capture

  • More than 70% of consumers prefer purchasing products in their native language, according to CSA Research, and many won’t buy at all if the experience isn’t localized

  • Non-English e-commerce markets are projected to exceed $1 trillion in revenue, with significant portions of that traffic flowing through organic search

Multilingual SEO combines translation, cultural localisation, and technical SEO to capture this demand. When done correctly, brands can expect higher international organic traffic, improved engagement metrics, more qualified leads, and increased global revenue.

For enterprise or high-complexity sites serving 20-40 languages, a robust and scalable multilingual strategy must be built from day one. Retrofitting proper multilingual architecture onto a poorly planned site is exponentially more expensive than building it right the first time.

Multilingual SEO vs international SEO: language-first vs country-first

Teams frequently confuse these two concepts, which leads to structural mistakes that are painful to fix later.

Let’s clarify the distinction.

  • Language-first (multilingual) prioritises serving the right language regardless of country. A single Spanish-language version serves users in Spain, Mexico, Argentina, and anywhere else Spanish speakers search. One set of URLs, one content strategy per language.

  • Country-first (international) creates separate experiences per locale, even when the same language is used. US, UK, and Australian visitors all get English—but different English experiences tailored to local pricing, regulations, and preferences.

Here’s a concrete example using Nike’s hypothetical URL structures:

  • Language-first: nike.com/es/ serves all Spanish speakers globally

  • Country-first: nike.com/es-es/ for Spain, nike.com/es-mx/ for Mexico—different content, pricing, and perhaps even product availability

When does each approach make sense?

Approach Best For Consider When
Language-first Wide global presence, limited resources, similar offers across regions Your products/services don’t vary by country and you want to consolidate domain authority
Country-first E-commerce with regional pricing, localised logistics, legal requirements vary Pricing, regulations or product availability differ significantly by market

For the Fortivus project, Blu Mint chose a language-first architecture because its B2B service offering is consistent across all 40 target languages. There was no need to create separate Spanish experiences for Spain versus Latin America—one localised Spanish experience serves all Spanish-speaking potential clients.

Planning your multilingual SEO strategy

Success starts with market and language choices, not with installing a translation plugin or enabling auto-translation. Before touching any technical configuration, you need a clear plan.

Start by mining your existing data:

  • Review Google Analytics to identify which countries and languages already drive traffic

  • Check your CRM for lead origins—where are inquiries coming from?

  • Analyse referral sources to spot international interest signals

Next, rank potential languages by three factors:

  1. Search demand: What’s the search volume for your key topics in each language?

  2. Revenue potential: Which markets have purchasing power and fit your offer?

  3. Operational capacity: Can you actually support customers in this language?

A critical planning decision: start with 3-5 core languages before scaling to 10+ or 40+. Launching thin, half-translated experiences hurts more than it helps. Each language version must deliver a complete user journey.

Your planning must cover:

  • Target languages in priority order

  • Content scope (entire site vs. priority sections only)

  • Governance and approval workflows

  • Update and sync processes across languages

At Blu Mint, we typically prioritise core conversion paths—home page, services/product pages, pricing, and contact forms—before expanding into long-tail content like blog posts in each new language.

Choosing the right URL structure for multilingual SEO

Each language version must have a unique, crawlable URL. Avoid auto-translate overlays or URL parameters for language targeting—these can cause serious indexing issues.

You have three viable URL structure options:

Structure Example Pros Cons
ccTLDs example.de Strongest geo signal, clear country targeting High maintenance, splits domain authority, expensive
Subdomains de.example.com Flexible, easy to set up Splits link equity, treated as separate sites
Subfolders example.com/de/ Consolidates authority, easiest to scale Less geo-specific signal than ccTLD

For most multilingual implementations, subfolders win.

They consolidate domain authority (studies show 20-30% ranking improvements versus fragmented structures), require less technical overhead, and scale gracefully from 3 languages to 40.

Critical warning: Never use URL parameters like ?lang=de for language targeting. Google explicitly discourages this pattern because parameters are often excluded from indexing, creating invisible language versions that search engines can’t properly crawl.

For a simple 3-language site, your structure looks like:

Each appears in search results with its respective language URL, and users land directly on their preferred language version.

For the Fortivus Squarespace website, Blu Mint used language-specific subfolders with hard-coded navigation. A full ccTLD network would have been overkill for 40 languages and would have fragmented their domain authority across dozens of separate domains.

Language-only vs language-and-locale structures

Beyond choosing subfolders, you need to decide between language-only URLs and language-plus-locale URLs.

  • Language-only (example.com/es/): One Spanish version serves all Spanish speakers globally. This works when your offers, pricing, and regulatory requirements are similar across Spanish-speaking markets.

  • Language-and-locale (example.com/es-es/ and example.com/es-mx/): Separate Spanish experiences for Spain and Mexico. This is necessary when pricing differs significantly, legal requirements vary, or product availability changes by country.

A language-first multilingual strategy typically starts with language-only structures and evolves into country variants only when data justifies the added complexity. Don’t create region-specific variants unless you have meaningful content differences to put in them.

Fortivus uses language-first hreflang annotations (es, fr, de) instead of 40 different language-region pairs. This simplifies management dramatically while still serving each target audience effectively.

Multilingual URLs: native characters vs English slugs (Greek & Ukrainian example)

When building multilingual websites, one overlooked but important decision concerns URL character sets—particularly for languages that use non-Latin scripts such as Greek or Ukrainian.

For example:

On the Fortivus website, Blu Mint deliberately retained English URL slugs across all language folders, even for languages using non-Latin alphabets. So instead of:

  • fortivus.com/el/υπηρεσίες/

or

  • fortivus.com/ua/послуги/

We used:

  • fortivus.com/el/services/

  • fortivus.com/ua/services/

Why?

Because URLs containing native Greek or Cyrillic characters become per cent-encoded when copied or shared. For example, a Russian URL like the one used on MoneyHub:

https://moneyhub.ee/ru/%d0%b8%d0%bd%d1%84%d0%be%d1%80%d0%bc%d0%b0%d1%86%d0%b8%d1%8f/%d1%81%d1%82%d0%b0%d1%82%d1%8c%d0%b8/

The URL is technically valid and SEO-friendly, but when shared via email, CRMs, Slack, or social media, it often appears as a long string of encoded characters. That affects:

  • Shareability

  • Trust perception

  • Click-through rates

  • Clean backlink acquisition

Does Google support native characters in URLs?

Yes. Google fully supports UTF-8 characters in URLs, including Greek and Cyrillic. From a pure indexing perspective, native-language slugs can even slightly improve keyword relevance in that language.

However, SEO decisions are not only about indexing. They are about:

  • User behaviour

  • Link sharing

  • B2B distribution

  • Cross-platform readability

  • Technical simplicity

For Fortivus, which serves global B2G and B2B audiences, clarity and professional link sharing mattered more than marginal keyword gains from translated slugs.

When should you use native character slugs?

Use native-language slugs when:

  • Your audience is primarily consumer-focused and domestic

  • URLs are rarely shared in encoded form

  • You operate primarily within that language ecosystem

  • Local SERP optimisation outweighs distribution concerns

MoneyHub, for example, targets Russian-speaking users directly in a consumer finance context. Native-language URLs align with user expectations and search behaviour.

When should you keep English slugs across all languages?

Keep English slugs when:

  • You operate in B2B or institutional environments

  • URLs are frequently copied into documentation or proposals

  • You serve multiple countries per language

  • Platform constraints complicate encoded URL handling

  • You prioritise clean, universal link structures

Fortivus chose English slugs inside language subfolders to maintain:

  • Clean link previews

  • Simpler internal governance

  • Easier CMS management at a 40-language scale

  • Consistent cross-language URL mapping

This is a strategic trade-off—not a technical limitation.

In multilingual SEO, the “right” decision depends on your audience, distribution model, and operational complexity.

Core technical foundations: HTML lang, hreflang & sitemaps

Technical signals enable Google and other search engines to serve the correct language version in search results. Get these wrong, and your carefully localised content might never reach its intended audience.

  • HTML lang attribute: Every page must declare its language in the HTML lang attribute. For an English page: <html lang="en">. This tells browsers and assistive technologies which language the content is in.

  • Hreflang annotations: These link all language equivalents so they don’t compete or cannibalise each other in search results. Without hreflang, Google might index your Spanish page and show it to English searchers, or vice versa.

  • Multilingual sitemaps: Maintain separate XML sitemaps per language (sitemap-en.xml, sitemap-es.xml) or use annotated entries within a single sitemap. This helps search engines efficiently discover and index all language versions.

These technical foundations must be validated with SEO tools and log file analysis, especially after launches or significant content updates. A single hreflang error can cascade into indexing problems across multiple language versions.

On the Fortivus Squarespace build, Blu Mint implemented hreflang via custom code injections and template modifications. Squarespace doesn’t natively support hreflang at scale, so we built the functionality manually across all 40 languages.

Implementing hreflang correctly

Hreflang errors are among the most common multilingual SEO issues—SISTRIX audits suggest roughly 70% of multilingual sites have implementation problems. Careful execution is essential.

The basic pattern: each page must list all its language equivalents plus a self-referencing hreflang tag. If you have English, Spanish, and German versions of a page, each of those three pages needs hreflang annotations pointing to all three (including itself).

The syntax uses ISO language codes:

  • Language only: hreflang="es" (Spanish for all Spanish speakers)

  • Language-region: hreflang="es-MX" (Spanish specifically for Mexico)

  • x-default: Used for users whose language doesn’t match any version

For a site with three languages, imagine each page contains references connecting:

  • English homepage → Spanish homepage → German homepage (and back)

  • English service page → Spanish service page → German service page (and back)

The x-default attribute typically points to either a global English page or a language selection page when no better match is available based on a user’s browser settings.

For Fortivus, Blu Mint used hreflang with language-only hreflang attributes (fr, de, pt, etc.) because each language serves multiple countries from the same content. Using language-region codes such as de-DE, de-AT, and de-CH would have tripled our annotation complexity without any meaningful benefit.

Multilingual sitemaps & indexation control

Sitemaps are essential for rapid discovery and accurate indexing of multiple language versions.

Best practice is creating one main sitemap index file that links to individual language sitemaps:

  • /sitemap-index.xml (master file)

  • /sitemap-en.xml (English pages)

  • /sitemap-fr.xml (French pages)

  • /sitemap-de.xml (German pages)

Include only canonical, indexable URLs in your sitemaps. Each localised URL should appear in its correct language sitemap—not scattered across multiple files.

Submit all sitemaps to Google Search Console and Bing Webmaster Tools. Monitor index counts by language to catch problems early. If your German sitemap has 500 URLs but only 300 are indexed, something needs investigation.

Periodically audit your sitemaps to remove old URLs, add new localised pages, and keep crawl budget efficient. On sites with 40 languages and hundreds of pages per language, sloppy sitemap management wastes crawl resources and delays indexing of new content.

Translation & localisation for SEO (not only words)

Multilingual SEO is not literal translation—it’s about intent, culture, and search behavior. Machine translation alone produces error rates exceeding 20% for nuanced SEO copy, which can destroy both rankings and user trust.

Professional translation services combined with native speaker review deliver dramatically better results than automated approaches. Work with translators who understand SEO principles and can maintain your brand message across various languages.

Localisation extends beyond words:

  • Adapt measurements and units (metric vs. imperial)

  • Convert currencies and pricing formats

  • Adjust date formats (MM/DD/YYYY vs. DD/MM/YYYY)

  • Modify legal notices and compliance language per region

At Blu Mint, we work with SEO-aware translators who understand that target keywords and UX microcopy must be adapted, not just translated. “Buy now” might be “Comprar ahora” in Spanish, but the button text that actually converts best might differ by market.

Don’t forget translated content that lives outside body copy:

  • Text inside images and graphics

  • CTAs and button labels

  • Form field labels and validation messages

  • Error messages and confirmation screens

Build an internal “multilingual content playbook” documenting tone, terminology standards, approved examples, and do/don’t guidelines for all translators working on your site.

Conducting keyword research in each language

A direct translation of English keywords often fails. The search term “footwear” might have high volume in English, but its literal translation might be rarely searched in Spanish, where “sneakers” or “tennis shoes” equivalents dominate.

Start from the real user language:

  1. Have native speakers brainstorm how they would naturally search for your offer

  2. Validate these terms using local keyword research tools

  3. Compare volumes and competition levels

Use tools like Semrush, Ahrefs, or language-specific alternatives to gather volumes and SERP examples for each target language. Don’t assume search behaviour mirrors English patterns—it rarely does.

Involve translators early in your process. Share your top English keyword set and ask them to propose equivalents matching actual search patterns in their language. A local market expert knows that Spanish speakers might search in ways that differ from the literal translation.

Blu Mint typically locks a keyword map per language (mapping each URL to primary and secondary keywords) before any translation work begins. This ensures that every translated page targets real search demand, not imaginary keywords that no one types.

On-page optimisation for each language

Each localised URL must be fully optimised, treated as a primary language page, not as an afterthought. The French version of your service page deserves the same attention as the English original.

Requirements for each language version:

  • Unique title tags under 60 characters using target language keywords

  • Unique meta descriptions written for click-through in that language

  • Properly translated and keyword-optimised H1s and H2 headers

  • Localised URL slugs (/es/marketing-digital/ instead of /es/digital-marketing/)

Internal links within a language section should primarily point to pages in the same language. If someone is reading your Spanish blog, links should lead to other Spanish content—not suddenly dump them into English articles.

Don’t forget structured content elements:

  • FAQ sections translated and optimised

  • Image alt attributes in the local language

  • Schema markup text fields translated appropriately

Information architecture & UX for multilingual sites

Site structure and navigation must feel coherent and predictable across all languages. Users should never feel lost simply because they switched from English to German.

Keep the same core information architecture across languages.

Your menu labels and page hierarchy should mirror each other, adapting only when content or legal needs genuinely differ. If English has “Services > Consulting > Strategy,” German should have the equivalent structure.

Mirror URL patterns so that switching languages leads users to the equivalent page, not just the homepage. If I’m on /en/pricing/ and click the French version, I should land on /fr/pricing/—not the French homepage.

Partial translations create broken user experiences. If only your blog is translated to Spanish, but nothing else is, Spanish-speaking visitors click from a blog post to your services page and suddenly can’t read anything. Prioritise full key journeys per language.

For Fortivus, Blu Mint designed language-specific headers and footers that are coded directly into Squarespace, ensuring clean, consistent navigation across all language versions. Global components such as footer links, legal pages, and privacy policies are maintained in every active language.

Designing effective language switchers

A language switcher allows users to correct auto-selection and move between different languages. Getting this wrong frustrates international visitors; getting it right builds trust immediately.

Placement principles:

  • Desktop: The top right corner of the header is standard

  • Mobile: Top of hamburger menu or prominent footer placement

  • Consistent location across all pages

Use language names written in their own language—Deutsch, Français, Español—rather than flags alone. Flags represent countries, not languages. A Spanish flag confuses Mexican users; a Brazilian flag alienates Portuguese speakers.

When you have more than 3-4 language options, dropdowns prevent visual clutter. Consider grouping languages logically (by region or alphabetically) for easy scanning.

For Fortivus’s 40-language Squarespace site, Blu Mint custom-built a clean dropdown language selector appearing on the home root domain. Displaying 40 language links in every header would overwhelm both mobile and desktop users. The drop-down menu approach maintains visual cleanliness while providing access to all language options.

The switcher should ideally link to the same URL path in the chosen language. Clicking “Deutsch” on /en/services/ should take users to /de/services/—not the German homepage.

Structured data & schema for multilingual SEO

Schema markup helps search engines understand content type and relationships, which becomes critical on large multilingual sites where the same entity appears in many different language versions.

Implement schema types like Organization, LocalBusiness (where relevant), Product, Service, and FAQ in every language version. Search engines use this structured data to generate rich results, and missing schema on your German pages means missing rich result opportunities in German search.

Text fields inside the schema should be translated:

  • Description fields in the local language

  • Product names that users would search for

  • FAQ questions and answers are fully localised

Identifiers like product IDs, SKUs, and organisation identifiers typically remain consistent across languages—they’re the same entity, just described differently.

Maintain consistent @id URLs per entity across languages so search engines recognise them as the same item with different language views. This prevents Google from treating your English and German product pages as completely unrelated entities.

Blu Mint used extensive schema on Fortivus to clarify their complex B2B service offering across 40 languages on Squarespace, improving rich result eligibility in multiple markets. Periodic validation using tools like Google’s Rich Results Test catches translation errors or syntax problems before they impact search performance.

Working with “Non-Multilingual-Native” platforms (e.g., Squarespace)

Platforms like Squarespace, Webflow, and some headless setups aren’t built for large multilingual sites out of the box. That doesn’t mean they can’t be used—it means you need a more sophisticated approach.

Common platform constraints include:

  • Limited native language management features

  • No built-in hreflang implementation

  • Global navigation components that resist per-language customisation

  • Template systems that fight against language-specific variations

Blu Mint’s approach with Fortivus demonstrates what’s possible. We built an enterprise SEO-grade multi-language website on Squarespace using:

  • Extensive CSS injections for language-specific styling

  • JavaScript implementations for dynamic language detection and switching

  • Code injections simulating language-specific headers and footers

  • Manual hreflang annotations added via custom code blocks

Each language version has its own page set within Squarespace, wired into language-specific menus and hreflang annotations that Squarespace doesn’t natively provide.

The front-page language selector presented a unique challenge. Displaying 40 languages visibly would overwhelm any interface. We designed a clean dropdown that provides full language access without cluttering the mobile or desktop experience.

Whilst such setups are complex, they prove that enterprise-grade multilingual SEO is achievable even on platforms not traditionally chosen for this purpose. The platform matters less than your technical SEO execution and overall strategy.

Content governance, QA & ongoing maintenance

Multilingual SEO is an ongoing programme, not a one-time project. With 10+ languages, governance becomes essential to maintaining quality and consistency.

Establish workflows where any change in the source language (typically English) automatically triggers update tasks for all relevant translations. If you update your pricing page in English, every other language version needs the same update—and someone needs to track that it has been updated.

Periodic content audits by language should happen every 6-12 months:

Get native speakers to regularly check UX elements for each major language. Forms, CTAs, and microcopy drift over time and can become dated or awkward. A button labelled “Get Started” from three years ago might now sound stale in the local market.

Translation memory and glossaries help ensure consistent terminology across new content, product launches, and campaigns. When your product name changes or you add new services, glossaries ensure all 40 languages use consistent terminology.

Blu Mint typically sets up editorial calendars with flags for localisation milestones, ensuring launches in new markets or additional languages stay synchronised with the source content.

Measuring multilingual SEO performance

You must track performance by language—and, where relevant, by country—to refine your strategy over time. Aggregate metrics hide language-specific problems and opportunities.

Analytics setup:

  • Create segments or views in Google Analytics by language folder (/fr/, /de/)

  • Consider separate properties in GA4 for major language sections

  • Alternative tools like Matomo can offer additional language segmentation options

Search Console configuration:

  • Create separate URL prefix properties for each language subfolder

  • Monitor index coverage by language

  • Track impressions and clicks per language version

Key metrics to monitor per language:

Metric What It Tells You
Organic sessions Overall traffic health
Impressions Search visibility in that language
CTR Title/description effectiveness
Rankings Keyword position competitiveness
Conversions Business impact per language
Revenue ROI justification for localisation efforts

Build dashboards showing side-by-side language comparisons. These highlight which languages need additional content investment, link-building focus, or technical fixes.

Blu Mint runs regular technical and content audits across languages, checking index coverage, Core Web Vitals scores, and hreflang errors to keep multinational sites healthy and performing.

Case Snapshot: how Blu Mint built a 40-language Squarespace site for Fortivus

The Fortivus website represents enterprise-level multilingual SEO on a platform explicitly not built for it. Here’s how we made it work.

  • The challenge: Build a 40-language, SEO-driven website on Squarespace with proper hreflang implementation, structured data, and a clean user experience across all devices.

  • The architecture: Language-first design with a single root domain and language-based subfolders. Hreflang annotations use language-only codes (es, fr, de) rather than language-region combinations, dramatically simplifying management while still serving a global audience effectively.

  • The technical solution: Since Squarespace lacks native multilingual support at this scale, we implemented:

    • Extensive CSS injections sitewide and on individual pages

    • Custom code injections for hreflang and schema implementation

    • Hard-coded headers and footers for each language version

    • A 40-language dropdown selector on the homepage is designed to remain clean on both mobile and desktop

  • Schema and optimisation: Large-scale schema markup deployed across all languages ensures each version can earn rich results independently. Consistent meta optimisation gives every language version the same fighting chance in its respective search results.

  • The outcome: A search-ready, enterprise-grade multilingual presence on Squarespace proving you don’t always need a heavyweight CMS if your technical SEO foundation and strategy are strong.

Next steps for your own multilingual website

Effective multilingual SEO blends strategy, technical execution, and high-quality localisation. There are no shortcuts—but there is a clear path forward.

  • Core pillars to remember:

    • Choose target languages based on data, not assumptions—analyse where demand and revenue potential actually exist

    • Pick the right URL structure (subfolders for most cases) and implement language-specific URLs consistently

    • Implement hreflang tags and HTML lang attributes correctly across all pages

    • Localise content with real keyword research per language, not just word-for-word translation

  • Platform limitations can be overcome: The Fortivus 40-language site demonstrates that careful technical work and information architecture can enable even “non-multilingual” platforms to operate at enterprise scale. The website builder matters less than your execution.

  • Start focused, then scale: Begin with 3-5 core languages where you can deliver complete, high-quality experiences. Prove ROI, establish governance workflows, then expand systematically with strong QA processes.

  • When complexity exceeds internal capacity: Enterprise teams needing complex, multi-language builds—even on platforms like Squarespace—benefit from working with an SEO agency that has executed this at scale. The technical details matter, and mistakes compound across every language version.

If you’re planning a multilingual website serving a global audience across new markets, or struggling to make your current international SEO work properly, reach out to Blu Mint.

We’ve built it, broken it, fixed it, and scaled it across dozens of languages—and we can help you do the same.

/* Blu Mint table - polished */ .bm-table-wrap{ margin: 28px 0 36px; border: 1px solid rgba(0,0,0,.10); border-radius: 14px; overflow: hidden; background: #fff; box-shadow: 0 8px 20px rgba(0,0,0,.04); } table.bm-table{ width: 100%; border-collapse: separate; border-spacing: 0; table-layout: fixed; font-size: 16px; line-height: 1.55; } table.bm-table thead th{ text-align: left; font-weight: 800; padding: 14px 16px; background: rgba(86,188,205,.10); /* cyan tint */ border-bottom: 2px solid #56BCCD; /* Blu Mint cyan */ } table.bm-table td{ padding: 16px; vertical-align: top; border-bottom: 1px solid rgba(0,0,0,.08); } table.bm-table tbody tr:last-child td{ border-bottom: none; } table.bm-table tbody tr:hover{ background: rgba(202,46,137,.04); /* subtle magenta hover */ } /* Column widths */ table.bm-table th:nth-child(1), table.bm-table td:nth-child(1){ width: 22%; } table.bm-table th:nth-child(2), table.bm-table td:nth-child(2){ width: 34%; } table.bm-table th:nth-child(3), table.bm-table td:nth-child(3){ width: 44%; } /* Approach labels */ .bm-label{ font-weight: 800; color: #111; border-left: 4px solid #CA2E89; /* Blu Mint magenta */ padding-left: 12px !important; } /* Mobile: keep readable without crushing columns */ @media (max-width: 768px){ .bm-table-wrap{ overflow-x: auto; -webkit-overflow-scrolling: touch; } table.bm-table{ min-width: 760px; } /* forces horizontal scroll */ }
Next
Next

The AI search playbook: lessons from BrightonSEO San Diego