Fundamentos de SEO técnico para tiendas Shopify

Casi todo el consejo de SEO técnico está escrito para un CMS donde controlas la tabla de rutas. Shopify no es eso. La plataforma fija la forma de cada URL, genera más de las que pediste, y deja las partes que de verdad importan — canonical, datos estructurados, hreflang — a lo que tu tema haga por su cuenta. Saber cuáles puedes cambiar y cuáles tienes que rodear es la mayor parte del trabajo.

La estructura de URLs es de la plataforma, no tuya

Cada recurso de la tienda vive bajo un prefijo fijo. Los productos en /products/<handle>, las colecciones en /collections/<handle>, las páginas en /pages/<handle>, los artículos en /blogs/<blog>/<article>. Puedes editar cada handle. No puedes quitar un prefijo, anidar un producto bajo una ruta de categoría ni inventar una ruta de primer nivel. Un plan de migración que asume /hombre/zapatos/runner-01 es un plan que no sobrevive al contacto con la plataforma.

Acepta eso temprano y lo demás se simplifica. El handle es la palanca que tienes, y es buena: es la única parte legible de la URL, se mantiene estable si no la tocas, y cambiarla después del lanzamiento cuesta un redirect y parte de la señal acumulada en la dirección anterior. Define los handles con criterio durante la migración, mientras nada está indexado, y después déjalos en paz.

El único punto donde la plataforma trabaja activamente en tu contra es la URL de producto dentro de una colección. Un producto alcanzable desde una colección también responde en /collections/<coleccion>/products/<handle>. Un producto que vive en doce colecciones tiene entonces trece direcciones que funcionan. El canonical de un tema competente apunta todas a /products/<handle>, que es el comportamiento correcto y lo primero que hay que verificar en cualquier tema que no escribiste tú. Es una revisión de una línea y está mal lo bastante seguido como para hacerla el primer día.

Las colecciones son de donde sale la duplicación

Rutas de tag

Shopify sirve las colecciones filtradas por tag en direcciones propias: /collections/zapatos/impermeable, y las combinaciones en /collections/zapatos/impermeable+talla-42. Son páginas reales y rastreables. Con ocho tags en una colección ya generaste una superficie combinatoria que nadie enlazó a propósito y que nadie quiere indexada.

La regla que vale la pena aplicar: una ruta de tag se gana la indexación solo si una persona la buscaría y la página tiene suficientes productos como para valer la llegada. "Zapatos de running impermeables" quizá. "Impermeable + talla 42 + azul" no. Todo lo que quede por debajo de esa línea recibe un canonical de vuelta a la colección padre o un noindex, y cualquiera de los dos es mejor que dejarlo abierto.

Filtros y el archivo robots

El filtrado de la tienda añade parámetros de consulta. Los parámetros son un problema más leve que las rutas de tag porque la mayoría de los temas los canonicaliza por defecto, pero "la mayoría de los temas" no es "tu tema". Revisa qué canonical emite una colección filtrada. Si se auto-canonicaliza a la URL filtrada, le entregaste a un rastreador un espacio sin fondo que explorar, y lo va a explorar.

Shopify permite editar robots.txt.liquid, que es el instrumento contundente para esto. Sirve para el espacio de parámetros y para las páginas de resultados de búsqueda interna, y es la herramienta equivocada para cualquier cosa que además quieras desindexar — una URL bloqueada no se puede rastrear, así que un rastreador nunca lee el noindex que le pusiste. Bloquea lo que nunca debe pedirse; pon noindex a lo que debe pedirse y no listarse. Confundir ambas cosas es como una página se queda meses en el índice sin descripción debajo.

Colecciones casi vacías

Las colecciones automáticas son baratas de crear, y por eso las tiendas terminan con cien de ellas y un tercio con dos productos cada una. Una colección con dos productos es una página sin razón para existir en un índice: compite con los productos mismos, no tiene nada que alguien haya buscado, y en conjunto estas páginas le dicen a un rastreador que el sitio son mayormente estantes vacíos.

Define un piso — un número de productos por debajo del cual una colección no se indexa — y aplícalo en la plantilla, no de memoria. La alternativa no es "unas cuantas páginas flacas". Es una acumulación lenta que nadie audita hasta que alguien se pregunta por qué las colecciones dejaron de posicionar.

Canonical y paginación son el mismo problema

Los temas exponen el canonical_url de Shopify y casi todos lo imprimen, así que la pregunta nunca es si tienes canonical sino si dice lo que querías decir. Tres casos explican casi todos los errores.

El primero es la URL de producto dentro de colección de arriba. El segundo es una colección filtrada u ordenada que se auto-canonicaliza. El tercero es la paginación, y es el que se equivoca en la dirección contraria: la página dos de una colección debe canonicalizar a la página dos, no a la uno. Apuntar todas a la primera le dice al rastreador que las páginas dos a nueve no existen, que es una manera rápida de perder los productos que solo aparecen al fondo de una colección.

Rel prev/next ya no es una señal por la que valga la pena diseñar. Lo que importa es que cada página paginada sea auto-canónica, que los productos del fondo de una colección se alcancen en pocos clics, y que el tamaño de página no sea tan chico que una colección de novecientos productos se convierta en treinta y ocho páginas de rastreo sin motivo.

Shopify publica /sitemap.xml a partir de lo que esté en el canal de la tienda online, lo que lo vuelve una auditoría y no una palanca: si lista colecciones que nunca quisiste exponer, el arreglo es despublicarlas.

Los datos estructurados son del tema, y de un solo lugar dentro de él

Shopify no emite datos estructurados de producto por ti. Los emite el tema, los emiten las apps y los emite la app de reseñas, que es como una página de producto termina cargando tres bloques Product que no se ponen de acuerdo en el precio. Elige una fuente — un snippet en el tema — y borra el resto.

Lo que ese snippet debe decir es menos interesante que lo que no debe. Emite Product con nombre, descripción, imagen, sku, marca y un Offer con precio, priceCurrency y una availability que refleje el estado real de la variante. Emite BreadcrumbList si tus migas de pan son reales. No emitas aggregateRating salvo que las reseñas existan y se vean en la página; es la razón autoinfligida más común por la que una tienda pierde resultados enriquecidos.

Las variantes son la parte que pide pensarse. Un producto cuyas variantes están a distintos precios necesita un AggregateOffer con lowPrice y highPrice: un Offer a secas no tiene forma de decir "desde", y la disponibilidad tiene que seguir siendo honesta cuando la variante seleccionada está agotada. Un snippet que fija el precio de la primera variante es correcto en la vista por defecto y falso en todas las demás. Esto es trabajo de tema normal, y es donde los datos estructurados se arreglan de verdad en lugar de apilarse.

Ese mismo snippet hoy hace doble trabajo. Un motor de respuestas generativas que lee tu página de producto interpreta el mismo marcado, y una página cuyos datos estructurados contradicen su contenido visible es una página que se resume mal. Lo tratamos como un problema y no como dos — mira preparación para búsqueda con IA para ver dónde se solapan.

hreflang cuando usas Markets

Markets te da varios locales, monedas, y subcarpetas o dominios separados. Del lado SEO lo que importa es el bloque de alternates: cada URL localizada tiene que declarar todas las demás versiones localizadas de la misma página, incluida ella misma, más un x-default. El objeto hreflang_tags de Shopify genera esto, y un tema que omite la llamada no genera nada.

Dos modos de fallo vale la pena nombrarlos. El primero es un desajuste entre lo que declaran los alternates y lo que la URL realmente sirve — una etiqueta que dice es-mx para una página que renderiza en inglés es peor que ninguna etiqueta. El segundo es redirigir por IP: un rastreador que llega desde un país y es rebotado a la tienda de ese país nunca ve los otros mercados. Sirve lo que se pidió, y ofrece un selector en vez de un redirect.

Un mercado que vende el mismo idioma a otro país sí quiere un alternate: en-CA junto a en-US es como le dices a un buscador qué storefront atiende a qué país, y es el mecanismo documentado para segmentar por región. Lo que no merece dirección propia es un mercado que no cambia absolutamente nada. Nuestro trabajo de implementación de SEO ecommerce suele empezar dibujando cuál es el mapa de mercados de verdad, antes de emitir nada.

El orden en que conviene hacerlo

Primero los canonical, porque son baratos y deciden cuáles de tus muchas direcciones cuentan. Después la superficie de tags y filtros, porque es la mayor fuente de páginas que no querías. Después los datos estructurados, consolidados en un solo snippet. Después las colecciones casi vacías. Y al final hreflang, que solo importa cuando lo anterior es coherente — declarar alternates entre dos conjuntos de páginas duplicadas nada más duplica el desorden.

Nada de esto es una táctica de crecimiento y nada aparece como un pico. Es la capa que decide si el resto de tu trabajo es siquiera legible para un rastreador, y se queda arreglada una vez arreglada, que es más de lo que puede decir la mayoría del trabajo de SEO.