Posicionar un marketplace no se parece a posicionar una tienda online. En una tienda controlas el catálogo, el tono y cada descripción; en un marketplace el contenido lo suben terceros, el número de URLs crece sin que nadie lo decida y los mismos productos aparecen listados por vendedores distintos. Si además operas en varios idiomas, multiplicas todo eso por el número de mercados.
Esta guía recoge las estrategias que aplicamos en proyectos de marketplaces y plataformas multi-idioma: cómo conseguir contenido único cuando no lo escribes tú, cómo diseñar una arquitectura de URLs que escale sin ahogar el rastreo, cómo implementar hreflang sin romperlo y qué ha cambiado en los dos últimos años, con la búsqueda generativa entrando en escena.
SEO para marketplaces: desafíos únicos
El SEO para marketplaces tiene complejidades que una tienda online estándar no tiene: contenido generado por vendedores (de calidad variable), miles o millones de páginas (gestión de crawl budget), URLs dinámicas por filtros y búsquedas, contenido duplicado entre vendedores que venden los mismos productos, y la necesidad de posicionar tanto categorías como productos individuales.
A esa lista conviene añadir dos tensiones que aparecen siempre y que son más de negocio que de técnica. La primera es el conflicto entre crecimiento del catálogo y calidad indexable: el equipo comercial quiere dar de alta al mayor número posible de vendedores y referencias, mientras que desde SEO interesa que cada página publicada aporte algo. Cuando gana el primero sin contrapesos, el resultado es un catálogo enorme donde Google indexa una fracción y valora poco lo indexado.
La segunda es la volatilidad. En un marketplace los productos se agotan, los vendedores se dan de baja y las referencias desaparecen a un ritmo que no existe en un ecommerce propio. Cada baja es una URL que estaba posicionada y deja de existir, y la forma de gestionarlas —404, 410, redirección o página mantenida con alternativas— determina buena parte de la salud del dominio a medio plazo. Nuestra recomendación práctica: si el producto volverá, mantener la URL con stock cero y alternativas visibles; si no volverá pero hay un equivalente claro, redirigir con 301; y si no hay equivalente, devolver 410 y dejar que el índice se limpie.
Contenido único a escala
El mayor reto es generar contenido único para miles de páginas. Las fichas de producto subidas por vendedores suelen ser genéricas o copiadas del fabricante. Estrategias: implementar guías de contenido obligatorias para vendedores, generar automáticamente meta descripciones únicas combinando atributos del producto, y crear contenido editorial de valor en páginas de categoría que no dependa de los vendedores.
Esas tres palancas funcionan, pero su eficacia depende de cómo se implementen. Las guías obligatorias para vendedores solo se cumplen si el sistema las hace cumplir: mínimos de caracteres, campos de atributo obligatorios, bloqueo de la publicación cuando la descripción coincide por encima de cierto umbral con otra ya existente en la plataforma. Pedirlo en un PDF de onboarding no cambia nada; validarlo en el formulario de alta, sí.
La generación automática a partir de atributos es la solución realista para catálogos grandes, y hoy se apoya con frecuencia en modelos de lenguaje. Aquí conviene una advertencia: Google no penaliza el contenido por haber sido generado automáticamente, penaliza el contenido que no aporta valor. La diferencia práctica está en el material de partida. Una descripción generada a partir de atributos reales, específicos y verificados del producto puede ser útil; una generada a partir del nombre y poco más produce texto de relleno que ni convierte ni posiciona. La regla que aplicamos es sencilla: si la generación no parte de datos que un cliente querría conocer, el problema no es el generador, es la ficha.
El contenido editorial en categorías es la palanca más infravalorada y la que más independencia da, porque no depende de los vendedores. Guías de compra, comparativas de gamas, explicación de tallas o compatibilidades, preguntas frecuentes específicas de la categoría. Además de aportar texto único, son el tipo de contenido que se cita en respuestas generativas, cosa que una ficha de producto escueta rara vez consigue.
Contenido duplicado entre vendedores
Cuando veinte vendedores listan el mismo producto, tienes veinte páginas casi idénticas compitiendo entre sí. Hay dos enfoques y conviene elegir de forma consciente. El modelo de catálogo unificado agrupa todas las ofertas bajo una única ficha canónica del producto, con los vendedores como ofertas dentro de ella; es el modelo de los grandes marketplaces y el mejor para SEO, porque concentra señales en una sola URL. El modelo de ficha por vendedor es más sencillo de construir y más flexible comercialmente, pero obliga a decidir qué versión es canónica y a marcar el resto, con el riesgo de canibalización permanente.
Si ya estás en el segundo modelo y migrar no es viable a corto plazo, el mínimo exigible es una política de canonicals coherente —normalmente hacia la oferta con mejor disponibilidad y datos más completos— y una revisión periódica de qué URLs están efectivamente indexadas.
Arquitectura de URLs para marketplaces
La arquitectura debe escalar sin crear problemas de indexación. Patrón recomendado: /categoria/producto-nombre para productos, /tienda/nombre-vendedor para perfiles de vendedor, y /categoria?filtro=valor con canonicals y noindex para filtros. Evita profundidades de URL de más de 3 niveles y asegura que cada producto es alcanzable en máximo 3 clics desde la home.
Navegación facetada y crawl budget
La navegación por filtros es, con diferencia, el mayor consumidor de rastreo en un marketplace. Cinco filtros con cinco valores cada uno generan miles de combinaciones, y si son combinables entre sí y además ordenables, el número de URLs distintas crece de forma explosiva. El propio Google advierte de que las URLs facetadas son caras de rastrear, y en auditorías reales es habitual encontrar que una parte enorme del presupuesto de rastreo se va en páginas de filtro que nadie quiere posicionar.
El planteamiento que funciona empieza por una decisión editorial, no técnica: qué combinaciones de filtros merecen ser páginas de aterrizaje. Normalmente son pocas y responden a búsquedas reales —»zapatillas running mujer talla 39″, por ejemplo—. Esas se convierten en URLs limpias, con título y contenido propios, y se enlazan desde la navegación. Todo lo demás se bloquea de forma ordenada: parámetros excluidos en robots.txt cuando no aportan nada, noindex cuando deben ser accesibles pero no indexables, canonical hacia la categoría base y enlaces internos con rel="nofollow" hacia las combinaciones que no interesan.
Conviene además vigilar tres detalles que se escapan con frecuencia: que los parámetros de ordenación y paginación no generen variantes indexables, que el sitemap incluya solo URLs indexables y canónicas —un sitemap con URLs bloqueadas o redirigidas envía señales contradictorias— y que los productos agotados no queden huérfanos de enlaces internos.
SEO multi-idioma: hreflang bien implementado
Para plataformas multi-idioma, hreflang es la pieza clave. Cada versión de idioma/país debe apuntar a todas las demás versiones equivalentes. Errores comunes: hreflang asimétricos (página A apunta a B pero B no apunta a A), mezclar idioma y país incorrectamente, y olvidar el tag x-default para la versión por defecto.
A esos tres errores clásicos añadimos los que más nos encontramos en auditorías recientes. El primero es la falta de autorreferencia: cada página del conjunto debe incluirse a sí misma en su propio bloque hreflang, y cuando falta, Google tiende a ignorar el conjunto entero. Es un fallo silencioso y muy extendido, porque la implementación «parece» correcta a simple vista.
El segundo es el conflicto entre hreflang y canonical. Si la versión francesa lleva un canonical apuntando a la española, le estás diciendo a Google que la página buena es la española y, a la vez, que sirva la francesa a los usuarios franceses. Ante la contradicción, el canonical gana y la versión francesa desaparece. Cada versión de idioma debe ser canónica de sí misma.
El tercero es declarar equivalencias que no existen. Si un producto solo está disponible en España, no inventes un hreflang hacia una versión francesa que redirige a la home o muestra un error. Es preferible no declarar la alternativa que declarar una falsa.
Sobre el formato: los códigos de idioma siguen ISO 639-1 y los de región ISO 3166-1 alpha-2, siempre en el orden idioma-región (es-MX, no mx-es), y la región es opcional. Un error frecuente es usar es-ES por defecto cuando en realidad quieres cubrir a todos los hispanohablantes: en ese caso lo correcto es es a secas, y reservar es-MX o es-AR para cuando de verdad existan versiones diferenciadas con precios y stock propios. En cuanto a la implementación, las tres vías —etiquetas en el <head>, cabeceras HTTP y anotaciones en el sitemap— son equivalentes para Google; en catálogos grandes, el sitemap suele ser la opción más mantenible porque centraliza las relaciones en un solo sitio en lugar de repartirlas por miles de plantillas.
Subdirectorios vs subdominios para idiomas
Para la mayoría de plataformas, recomendamos subdirectorios (site.com/es/, site.com/fr/). Consolidan la autoridad de dominio, son más fáciles de gestionar técnicamente, y Google los trata bien. Los ccTLDs (site.es, site.fr) dan señal geo más fuerte pero dividen la autoridad. Subdominios (es.site.com) son la peor opción en la mayoría de casos.
La excepción que justifica un ccTLD es la de negocios con operación realmente local: entidad jurídica en el país, atención al cliente en el idioma, logística propia y a menudo una marca que el mercado local reconoce mejor con su dominio nacional. En esos casos el coste de mantener varios dominios se compensa con confianza del usuario y señal geográfica. Fuera de ese escenario, arrancar con ccTLDs suele significar empezar de cero en autoridad tantas veces como países haya.
Un apunte que se olvida: la decisión de estructura es de las más caras de revertir. Migrar de subdominios a subdirectorios implica redirecciones masivas, revisión de hreflang, reindexación completa y, casi siempre, una caída temporal de tráfico. Si la plataforma está en fase de diseño, es el momento de acertar; si ya está en producción, el cambio debe planificarse como una migración formal con su análisis de riesgo, como detallamos en nuestra guía de migración entre plataformas de ecommerce.
Geolocalización y redirecciones automáticas
Una tentación habitual es redirigir automáticamente al usuario según su IP. Es mala idea para SEO: el rastreador de Google llega casi siempre desde Estados Unidos, así que si rediriges por IP, es probable que solo vea la versión estadounidense de todo y nunca llegue a rastrear el resto. La alternativa correcta es sugerir, no forzar: un banner o selector que proponga la versión local, deje cambiar y recuerde la elección, sin bloquear el acceso a ninguna versión.
Gestión de contenido traducido
No basta con traducir: necesitas localizar. Esto incluye: adaptar keywords al mercado local (no traducir literalmente, sino investigar qué buscan los usuarios en cada idioma), adaptar monedas y unidades, y considerar diferencias culturales en el contenido. La traducción automática con revisión humana es un buen equilibrio entre coste y calidad para catálogos grandes.
La investigación de keywords por mercado es donde más se nota la diferencia entre traducir y localizar. Un mismo producto puede llamarse de forma distinta en España y en México, y el término que la marca usa internamente rara vez coincide con el que busca la gente. Traducir la keyword española al francés produce, con frecuencia, una página optimizada para una expresión que nadie escribe en Francia. La única forma de evitarlo es hacer la investigación en cada idioma con datos locales, no partiendo del listado del mercado de origen.
Para catálogos de miles de referencias, el enfoque escalonado es el más sensato: traducción automática para la cola larga del catálogo, revisión humana para las categorías y productos que concentran el tráfico y la conversión, y redacción nativa para las páginas comerciales importantes y el contenido editorial. Priorizar la revisión por volumen de negocio, no por orden alfabético del catálogo, es lo que hace viable el presupuesto.
Conviene además no olvidar lo que no es texto visible: títulos y meta descripciones traducidos y no heredados del idioma original, atributos alt de las imágenes, datos estructurados con el idioma y la moneda correctos, formatos de fecha y de números adaptados, y los textos legales revisados por mercado —que además de ser un requisito normativo, son páginas que los usuarios consultan antes de comprar en un sitio que no conocen.
Datos estructurados: la capa que Google lee primero
En un marketplace, los datos estructurados no son un extra: son la forma en que Google entiende qué vendes, a qué precio y con qué disponibilidad. El marcado de producto con oferta, precio, moneda, disponibilidad y valoraciones es lo que habilita los resultados enriquecidos, y en catálogos con muchas referencias marca una diferencia real de visibilidad frente a los enlaces sin adornos.
Los puntos donde más veces hemos visto fallar la implementación son siempre los mismos: precio y disponibilidad marcados en el HTML pero desincronizados con lo que realmente muestra la página —lo que invalida el marcado—, valoraciones agregadas declaradas sin que existan reseñas visibles, y el marcado de un producto duplicado en varias URLs sin canonical claro. En plataformas multi-idioma se suma un cuarto: declarar la moneda del mercado de origen en todas las versiones, de modo que la versión francesa anuncia precios que no se corresponden con los que ve el usuario.
Para el caso concreto de tiendas y marketplaces, la vía canónica es enviar el catálogo a través de Merchant Center y mantener la coherencia entre ese feed, el marcado de la página y lo que finalmente se muestra. Cuando las tres fuentes dicen lo mismo, todo funciona; cuando difieren, el resultado es imprevisible.
Actualización 2026: qué ha cambiado con la búsqueda generativa
Desde la primera versión de este artículo, la novedad de fondo no es un cambio de algoritmo sino un cambio de interfaz: una parte creciente de las búsquedas se resuelve con respuestas generadas por IA, y eso altera los supuestos con los que se planificaba el SEO de un marketplace.
El primer efecto es sobre el tráfico esperado por posición. Cuando la consulta se resuelve con un resumen generativo, el clic a los resultados orgánicos cae aunque la posición no se mueva. La consecuencia práctica para un marketplace es que las consultas informativas —»qué talla de bota de montaña necesito», «diferencia entre dos tipos de material»— pierden capacidad de traer visitas, mientras que las transaccionales y las de producto concreto mantienen mucho mejor su valor. Eso reordena prioridades: el contenido editorial de categoría sigue siendo útil, pero más como material que puede ser citado y como apoyo a la conversión que como fuente directa de sesiones.
El segundo efecto es tranquilizador desde el punto de vista técnico. Las funciones generativas de Google se apoyan en el mismo índice y en los mismos sistemas de ranking que la búsqueda tradicional, así que no requieren datos estructurados especiales para IA, ni un fichero llms.txt, ni versiones alternativas del contenido en otro formato. Lo que hace que una página sea elegible sigue siendo lo de siempre: que esté indexada, que cargue, que responda a la intención y que sus datos sean coherentes. Dicho de otro modo, la preparación para la búsqueda con IA consiste en hacer bien el SEO técnico de toda la vida, no en añadir una capa nueva.
El tercer cambio es de medición: Search Console ha ido incorporando informes de rendimiento en superficies generativas, lo que permite ver impresiones en esas funciones separadas del resto. Es información útil para entender por qué una categoría pierde clics sin perder posiciones, que es el patrón más desconcertante de los últimos meses.
Para plataformas multi-idioma hay un matiz adicional que conviene tener presente: las señales de hreflang están pensadas para elegir la variante regional de un resultado, y en un flujo generativo la selección del contenido fuente ocurre antes de esa decisión. No es motivo para descuidar hreflang —sigue siendo determinante en los resultados clásicos y en la resolución de duplicados— pero sí para no esperar de él lo que no puede dar.
El rendimiento también es SEO internacional
Un marketplace multi-idioma suele servir a usuarios repartidos por varios países, y la distancia al servidor se paga en milisegundos. Una plataforma alojada en España que atiende tráfico mexicano sin CDN parte con desventaja en cada visita. A eso se suma que las páginas de categoría con muchos filtros y las fichas con galerías extensas son las plantillas más pesadas de cualquier catálogo.
Las Core Web Vitals no son un factor de ranking dominante, pero sí desempatan entre páginas comparables, y en un mercado con miles de competidores por consulta, los desempates importan. Además, el efecto sobre la conversión es inmediato y no depende de Google. Lo tratamos en detalle en nuestra guía de auditoría de rendimiento web y en el artículo sobre Core Web Vitals e INP.
¿Estás montando o escalando una plataforma multi-idioma?
En Keliam desarrollamos y optimizamos marketplaces y ecommerce internacionales: arquitectura de URLs, hreflang, gestión de catálogos multi-idioma, rendimiento e integraciones.
- Desarrollo Ecommerce — plataformas y marketplaces a medida
- Auditoría Técnica Web — indexación, rendimiento y arquitectura
- Mantenimiento Ecommerce — soporte continuo para tu plataforma
Checklist de auditoría para un marketplace multi-idioma
Cuando entramos a auditar una plataforma de este tipo, estos son los puntos que revisamos y en este orden, porque los primeros condicionan a los siguientes.
Indexación. Cuántas URLs tiene realmente el sitio frente a cuántas están indexadas, y qué proporción de lo indexado son páginas que interesan. Una diferencia enorme entre URLs rastreadas e indexadas suele apuntar a filtros descontrolados o a contenido demasiado fino.
Rastreo. Análisis de los registros del servidor para ver dónde gasta Google el tiempo. Si la mayor parte del rastreo se va en parámetros y paginaciones profundas, no hay contenido que valga.
Duplicados. Productos listados por varios vendedores, variantes de color o talla como URLs independientes, versiones con y sin barra final, con y sin www. Política de canonicals coherente y verificada, no solo declarada.
hreflang. Simetría, autorreferencia, ausencia de conflictos con canonical, presencia de x-default y correspondencia real entre las versiones declaradas.
Contenido. Proporción de fichas con descripción propia frente a copiadas, presencia de contenido editorial en categorías, calidad de las traducciones en las páginas que concentran negocio.
Datos estructurados. Validez del marcado, coherencia entre marcado, página y feed, y corrección de moneda e idioma por mercado.
Rendimiento. Core Web Vitals por tipo de plantilla y por país, no solo en la home.
Este esquema es el mismo que seguimos en la auditoría SEO para ecommerce, ampliado con las particularidades de catálogo multi-vendedor; y si buscas el detalle de cada comprobación técnica, está desarrollado en la guía completa de SEO técnico para ecommerce. Para quien esté todavía decidiendo la base tecnológica sobre la que construir, en la comparativa entre PrestaShop, WooCommerce y Magento analizamos cómo se comporta cada una con catálogos grandes y multi-idioma.
Preguntas frecuentes
¿Necesito hreflang si mis versiones están en el mismo idioma pero para países distintos?
Sí, y es precisamente el caso donde más falta hace. Dos versiones en español para España y México son casi idénticas para un algoritmo, y sin hreflang es probable que Google muestre la equivocada o consolide ambas en una. Con es-ES y es-MX correctamente declaradas, cada usuario recibe la suya.
¿Es mejor traducir todo el catálogo o solo una parte?
Depende de si puedes mantenerlo. Un catálogo traducido a medias, con fichas en un idioma y navegación en otro, genera mala experiencia y señales confusas. Si los recursos son limitados, es preferible abrir menos idiomas y cubrirlos bien que abrir muchos y dejarlos a medio hacer.
¿Cómo se gestionan los productos agotados o los vendedores que se dan de baja?
Si el producto volverá, mantener la URL con el stock a cero y alternativas visibles. Si no volverá pero hay un equivalente, redirección 301. Si no hay equivalente, 410 para que el índice se limpie. Lo que no funciona es dejar cientos de páginas vacías indexadas ni redirigirlo todo a la home.
¿Hay que hacer algo especial para aparecer en las respuestas generativas?
No hay una capa técnica separada: las funciones generativas usan el mismo índice y los mismos sistemas de ranking. Lo que ayuda es contenido que responda con claridad a preguntas concretas, datos coherentes entre página, marcado y feed, y una web indexable y rápida.
Conclusión
El SEO de un marketplace multi-idioma se gana en las decisiones estructurales, no en los ajustes finos. La estructura de dominio, el modelo de fichas de producto, la política de filtros indexables y el nivel de exigencia con el contenido de los vendedores determinan el techo de la plataforma; lo demás son mejoras sobre ese techo.
Si algo ha cambiado con la llegada de la búsqueda generativa es la importancia relativa de cada pieza: el contenido genérico de relleno vale menos que nunca, la coherencia de los datos vale más, y el tráfico informativo ya no se puede dar por descontado. Lo que no ha cambiado es que una plataforma con arquitectura limpia, hreflang correcto y fichas que dicen algo tiene ventaja sobre una que crece sin control. Esa ventaja se construye antes de que el catálogo llegue al millón de URLs, no después.
