SEO para tiendas multidioma y multipaís: catálogo y precios

Una tienda multidioma no es una tienda con el texto traducido. En cuanto vendes en dos países, cada producto deja de ser un único objeto y pasa a ser una familia de versiones: el mismo artículo con otro nombre, otro precio, otra moneda, otros plazos de envío y, a veces, otra disponibilidad. El SEO de ese catálogo consiste en decidir qué es común a todos los mercados, qué cambia por mercado y cómo se lo cuentas a Google de forma coherente en la página, en el schema y en el feed.

Este artículo trata solo esa mecánica de catálogo. No repasa la estrategia internacional ni la configuración de hreflang, que es otro tema; se centra en las decisiones que aparecen cuando ya tienes productos, precios y stock en juego: cómo son las URLs, cómo se declara el precio por país, qué hacer cuando un producto existe en un mercado y en otro no, y dónde suelen romperse las cosas.

Un producto, muchas versiones: el modelo de datos primero

Antes de tocar una URL conviene separar en el catálogo tres capas. La primera es la identidad del producto: el SKU interno, el GTIN o el MPN, la marca, las dimensiones y las fotos. Esa capa es idéntica en todos los mercados y es la que permite relacionar versiones entre sí. La segunda es la capa de idioma: nombre, descripción, atributos visibles, textos de categoría y metadatos. Depende del idioma, no del país. La tercera es la capa de mercado: precio, moneda, impuestos incluidos o no, plazos de entrega, costes de envío, política de devoluciones y stock.

El error habitual es mezclar la segunda y la tercera. Si tu sistema solo entiende el idioma, acabarás sirviendo el mismo precio en euros a un lector mexicano que escribe en español, o mostrando un precio sin IVA a un cliente que ve la etiqueta con IVA en el resto del catálogo. Una tienda bien modelada puede tener el mismo texto en español para España y México, pero dos precios, dos monedas y dos disponibilidades distintas.

Esta separación tiene consecuencias SEO directas. Lo que depende del idioma se traduce una vez y se reutiliza en todos los países que hablan ese idioma. Lo que depende del mercado debe poder cambiar sin tocar la traducción. Y lo que es identidad debe servir de clave común, porque es lo que te permite detectar duplicados, construir alternativas de idioma correctas y mantener feeds consistentes.

• Identidad (global): SKU, GTIN, marca, medidas, imágenes base.
• Idioma: nombre, descripción, atributos, texto de categoría, etiquetas de imagen.
• Mercado: precio, moneda, impuestos, envío, devoluciones, stock, promociones.

URLs de producto: traducidas o compartidas

Hay dos enfoques razonables para el slug del producto, y ninguno es universalmente superior. El primero es traducir el slug: /es/zapatillas-running-trail y /en/trail-running-shoes. Es más legible, ayuda al usuario a reconocer de qué trata la página en los resultados y permite que la palabra clave del idioma aparezca en la URL. El segundo es compartir un identificador: /es/p/84213 y /en/p/84213, o un slug base igual en todos los idiomas. Es más fácil de mantener y reduce el riesgo de que dos versiones se desincronicen.

Mi criterio práctico es traducir cuando el catálogo es curado y relativamente pequeño, y compartir un identificador estable cuando el catálogo es grande o cambia a menudo. Con miles de productos, traducir cada slug implica mantener miles de redirecciones cada vez que se corrige un nombre. Un compromiso frecuente es combinar ambos: un identificador numérico estable al final y un texto traducido delante, de modo que la parte textual pueda cambiar sin romper la resolución de la URL.

Sea cual sea el modelo, hay reglas que no cambian. Cada versión debe tener una URL propia y rastreable, sin depender de cookies, parámetros de sesión ni JavaScript para mostrar el idioma o el país. Cada URL lleva un canonical que apunta a sí misma, no a la versión en otro idioma; un canonical cruzado le dice a Google que ignore la versión traducida. Y si cambias un slug, la URL antigua debe responder con una redirección 301 a la nueva, dentro del mismo idioma y mercado.

Conviene además decidir cómo se codifica el mercado. Los subdirectorios (/es-mx/), los subdominios y los dominios por país son válidos; lo importante es que la elección sea consistente en todo el catálogo y que el país se pueda deducir de la URL. Esa es la base sobre la que luego se apoyan los feeds y el schema.

Mismo idioma, distinto país: el caso del español

El español es el ejemplo más incómodo porque varios mercados comparten idioma. Si publicas /es-es/ y /es-mx/ con el mismo texto, tienes dos páginas casi idénticas que solo se distinguen por el precio. Google puede tratarlas como duplicados y elegir una de ellas como canónica por su cuenta, lo que significa que un mercado podría mostrar la URL del otro, con la moneda equivocada.

La defensa no es fingir que son distintas, sino hacerlas genuinamente distintas en lo que importa para el comprador. El vocabulario cambia de verdad: ordenador y computadora, zumo y jugo, móvil y celular, coche y carro. Las tallas, las unidades de medida, los plazos, los métodos de pago, el tratamiento del IVA y la política de devoluciones también varían. Reflejarlo no es maquillaje: es lo que hace útil la página para quien compra.

Aun así, espera cierto solapamiento en las fichas de producto, sobre todo en las de marcas con descripciones del fabricante. Cada versión debe llevar su canonical autorreferente y su marcado de alternativas de idioma, y debes comprobar en Search Console qué URL elige Google como canónica en cada mercado. Si elige la del otro país de forma sistemática, la diferencia entre ambas páginas todavía es demasiado pequeña.

Moneda y precio en el schema Product

En el marcado Product, el precio vive dentro de Offer y se compone de dos campos que muchas tiendas estropean: price y priceCurrency. El precio debe ser un número con punto decimal y sin separador de miles ni símbolo, por ejemplo 1299.90, y la moneda debe ser el código ISO 4217 de tres letras: EUR, MXN, USD, COP. Escribir 1.299,90 € en el campo price es un error clásico de las tiendas que montan el schema a mano con el formato local.

La regla de fondo es que el schema debe describir lo que el usuario ve en esa URL. Si la página de /es-mx/ muestra 24.990 pesos, el marcado declara 24990 y MXN, no el precio base en euros convertido en el servidor. El desajuste entre marcado y página visible es la causa más frecuente de que los datos de producto se ignoren o de que aparezcan avisos en Search Console. Esto afecta también a la coherencia con impuestos: si la página muestra precio con IVA, el schema debe reflejar ese mismo importe.

Cuando el precio depende del mercado, cada URL declara una sola oferta: la de su mercado. No metas en una misma página un array con las ofertas de todos los países esperando que Google elija; lo que quieres es que cada URL sea coherente consigo misma. Las promociones siguen la misma lógica: priceValidUntil debe corresponder a la vigencia real en ese país, no a una fecha global copiada.

Si ofreces envío y devoluciones diferentes por país, el marcado de Offer admite detalles de envío y de política de devoluciones con su país de destino. Son datos que conviene declarar por mercado, porque el coste y el plazo de entrega forman parte de la decisión de compra y de lo que Google puede mostrar junto al producto.

Feeds por país: precios, moneda y coherencia con la web

En Merchant Center, el feed es la otra fuente que describe tu precio, y tiene que coincidir con la página de destino. La práctica habitual es mantener un feed, o al menos una configuración de destino, por cada combinación de país e idioma, con el precio en la moneda local y el enlace apuntando a la URL de ese mercado. Mezclar una URL en español de México con un precio en euros provoca discrepancias que acaban en rechazo de productos.

Los puntos donde más se falla son previsibles. El precio del feed se actualiza cada día, pero la web cambia de precio por una promoción y el feed no se entera hasta la siguiente carga. La moneda del feed es correcta, pero la página, al no detectar el país del rastreador, muestra otra moneda. O el identificador del producto cambia entre mercados y se pierde la relación entre versiones. Usa el mismo GTIN y, si puedes, el mismo ID interno en todos los países, y deja que cambien solo los atributos de mercado.

Si te interesa el detalle de los atributos del feed, cómo se estructura y cómo se diagnostican los rechazos, ya existe una guía dedicada al feed de productos en Merchant Center. Aquí la idea es otra: que el feed de cada país sea una proyección exacta de lo que esa URL de mercado muestra y declara en el schema. Si las tres fuentes (página, marcado y feed) cuentan lo mismo, la mayoría de los problemas desaparece.

Cómo decide la moneda un usuario y cómo la ve Google

Un selector de moneda que funciona con una cookie o con la detección por IP es cómodo para el usuario y una trampa para el rastreo. Googlebot rastrea sin cookies y, en general, desde direcciones de Estados Unidos. Si tu tienda decide la moneda por IP o por cookie, el rastreador verá casi siempre la misma versión, y las demás quedarán sin descubrir o serán vistas con la moneda equivocada.

La regla es que la moneda debe ser consecuencia de la URL, no de quién la visita. Cada URL de mercado muestra siempre su moneda. Si quieres ofrecer un convertidor, hazlo como una opción adicional que no cambie el contenido indexable, o que lleve a otra URL de mercado. Y si quieres sugerir al visitante otro país, usa un banner que le permita elegir, no una redirección automática que bloquee el acceso a la versión que el rastreador intenta ver.

Un detalle más: una tienda puede vender a un país sin tener una versión propia de la URL y cobrar en otra moneda, por ejemplo aceptando pagos en dólares desde toda Latinoamérica. Es una decisión legítima, pero entonces la URL representa al mercado en dólares, y no debes presentarla como específica de un país concreto ni esperar que rinda como una versión local.

Stock distinto por mercado sin romper el posicionamiento

Cuando un producto se agota en un país pero sigue disponible en otro, la tentación es devolver un 404 en el mercado sin stock. No lo hagas si el producto va a volver. Mantén la URL, muestra el estado agotado y declara la disponibilidad correcta en el schema, con OutOfStock si no hay existencias y con PreOrder o BackOrder si aceptas pedidos con espera. Así conservas la URL, su historial y los enlaces que recibe.

Distingue tres situaciones. La primera es agotado temporal: la URL se mantiene, con aviso de reposición y disponibilidad coherente con el schema y el feed. La segunda es producto no comercializado en ese país: no existe motivo para crear una ficha vacía; simplemente no publicas esa versión, y en el resto de mercados no declaras una alternativa hacia un país que no existe. La tercera es producto retirado del catálogo: redirección 301 a la alternativa más cercana del mismo mercado, o 410 si no hay equivalente.

Un fallo frecuente es dejar fichas de producto indexables con un estado de disponibilidad que contradice el feed. Si el feed dice que hay stock y la página dice que no, Merchant Center lo detecta y los productos se excluyen. Sincroniza las fuentes y, si el stock cambia a menudo, reduce la latencia entre la web y el feed en lugar de multiplicar correcciones manuales.

Categorías, facetas y contenido derivado por mercado

El catálogo no termina en la ficha de producto. Las categorías y los filtros heredan el problema: un listado de zapatillas ordenado por precio mostrará cifras distintas en cada mercado, y un filtro por rango de precio genera URLs que solo tienen sentido en una moneda. Decide qué facetas merecen URL indexable y cuáles no, y hazlo igual en todos los idiomas, para no acabar con una combinación indexada en un mercado y bloqueada en otro.

También conviene pensar en el contenido editorial de cada categoría. Traducir el texto es el mínimo; lo útil es adaptarlo a cómo se busca el producto en cada país. Las palabras clave no se traducen una a una: una categoría que en España se busca con un término puede buscarse con otro en México, y la investigación de palabras clave debe hacerse por mercado y no derivarse del idioma original.

Por último, revisa el sitemap. Los sitemaps por mercado, o con las alternativas de idioma declaradas, facilitan que cada versión se descubra y permiten vigilar la cobertura por país. Un sitemap que solo lista el mercado principal es un síntoma de que el resto del catálogo se está descubriendo por casualidad.

Lista de comprobación antes de publicar un mercado nuevo

Antes de abrir un nuevo país o idioma, recorre el catálogo con una lista corta. No sustituye a una auditoría completa, pero detecta los fallos que más daño hacen cuando ya hay tráfico y ventas en juego.

• Cada versión tiene URL propia, rastreable sin cookies, y un canonical que apunta a sí misma.
• El precio del schema es un número con punto decimal y una moneda ISO 4217, igual al importe visible.
• El feed del país usa la misma moneda, el mismo precio y la URL del mercado correcto.
• La disponibilidad coincide entre página, schema y feed, y los agotados temporales no devuelven 404.
• El envío y las devoluciones se declaran por país, no con un valor global.
• Las versiones de un mismo idioma se diferencian en vocabulario, impuestos, envío y pagos.
• Search Console muestra qué URL elige Google como canónica en cada mercado, y coincide con la tuya.
• Las redirecciones de slugs antiguos se quedan dentro del mismo idioma y mercado.