SEO en Wix: qué puedes hacer y qué no

SEO en Wix: qué puedes hacer y qué no

Wix arrastra una reputación de ser malo para el SEO que viene de una época muy concreta: los primeros años, cuando los sitios se construían sobre un motor de renderizado pensado para el editor visual y no para que un rastreador los leyera con facilidad, la versión móvil era un sitio espejo separado que generaba contenido duplicado, y el control sobre etiquetas, canonicals o velocidad era prácticamente nulo. Esa experiencia dejó cicatriz: quien probó Wix en ese periodo escribió sobre ello, y el veredicto se repitió por inercia mucho después de dejar de ser cierto. Hoy Wix indexa, renderiza y posiciona páginas como cualquier otro constructor de sitios serio, y seguir diciendo que "Wix no sirve para SEO" es información caducada disfrazada de prudencia.

Dicho esto, tampoco hay que irse al extremo contrario y tratar a Wix como técnicamente equivalente a un sitio construido a medida. No lo es, porque es una plataforma pensada primero para que cualquiera monte un sitio visualmente y solo después para darle margen técnico a quien sabe lo que hace. Este artículo separa las dos cosas: qué controlas de verdad desde el panel de Wix, dónde el diseño de la plataforma pone un techo que ningún ajuste levanta, en qué orden trabajar si no eres desarrollador, y cuándo migrar fuera realmente se justifica.

De dónde viene la mala fama, y qué queda de verdad

La crítica histórica no era infundada en su momento. Durante años, el sitio publicado dependía de un renderizado que los rastreadores no interpretaban bien, así que páginas que un visitante veía perfectamente podían llegarle a Google casi vacías. La plataforma mantenía además una URL móvil distinta de la de escritorio, lo que abría la puerta a contenido duplicado si el canonical no estaba bien resuelto. Y el control editorial sobre título, descripción o estructura de URL era mínimo comparado con lo que ya ofrecía cualquier gestor de contenidos con un plugin de SEO decente.

Wix reconstruyó buena parte de ese motor con el tiempo: unificó el renderizado para que lo que ve un rastreador se parezca a lo que ve un visitante, eliminó la versión móvil separada en favor de un diseño responsivo bajo la misma URL, y añadió un panel de SEO propio con controles que antes no existían. Esa parte de la historia está zanjada. Lo que no está zanjado es si la plataforma da el mismo margen técnico que tendrías fuera de ella, y ahí conviene ser honesto en los dos sentidos: ni sigue siendo el desastre de hace una década, ni es un terreno sin límites.

Qué te da el panel de Wix, de verdad

Dentro del propio editor hay una superficie de control razonable, y vale la pena saber exactamente qué cubre antes de asumir que hace falta un plugin externo o una migración para resolver algo que ya está resuelto:

Para la mayoría de sitios pequeños y medianos -un negocio local, un portafolio, una tienda con catálogo moderado- esta superficie cubre lo que hace falta para que el SEO on-page esté resuelto sin escribir una línea de código.

  • Título y meta descripción editables por página, con vista previa de cómo se vería el resultado en el buscador antes de publicar.
  • Slug de URL editable en cada página, para poder quitar los identificadores automáticos y dejar una ruta legible.
  • Sitemap XML generado y actualizado automáticamente cada vez que se publica o modifica contenido, sin que haga falta tocarlo a mano.
  • Gestor de redirecciones 301 integrado, útil cuando se cambia un slug o se elimina una página y no se quiere perder el enlazado que apuntaba a la URL antigua.
  • Controles de datos estructurados para los tipos de contenido más comunes -producto, artículo de blog, negocio local-, que Wix inserta automáticamente cuando se rellenan los campos correspondientes.
  • Renderizado móvil nativo bajo la misma URL que la versión de escritorio, así que ya no hay que gestionar el problema de contenido duplicado entre versiones que existía antes.
  • Etiqueta canonical configurable por página, y opción de marcar una página como no indexable cuando corresponde.

Dónde está el techo real

El techo no está en lo que el panel te deja tocar, sino en lo que la arquitectura de la plataforma decide por ti antes de que llegues al panel.

El primero es el renderizado y la entrega de contenido. Wix sirve cada sitio a través de su propia infraestructura, con su propio pipeline de renderizado y su propia red de entrega. No hay acceso a configuración de servidor, no se puede instalar una capa de caché propia ni elegir un proveedor de CDN distinto: se trabaja dentro de lo que la plataforma decide exponer, y ninguna optimización de bajo nivel está sobre la mesa.

El segundo es el techo de velocidad en plantillas cargadas y con muchas aplicaciones instaladas. Las plantillas visuales, sobre todo las más vistosas, cargan por defecto una cantidad considerable de JavaScript y CSS para sostener animaciones y elementos interactivos, y cada aplicación que se añade desde el mercado de Wix -un widget de reservas, un chat en vivo, un carrusel de reseñas- suma su propio peso de carga de forma independiente, casi siempre sin que el propietario tenga visibilidad real de cuánto está costando. El resultado habitual es que las métricas de Core Web Vitals de un sitio en Wix tienden a quedar por debajo de las de un sitio ligero construido a medida, incluso después de comprimir imágenes y quitar lo superfluo, porque la plantilla ya parte con un coste fijo que no se elimina del todo.

El tercero son las convenciones de URL que no se pueden evitar del todo. Aunque el slug de cada página es editable, ciertas secciones siguen una estructura que impone la propia plataforma: las entradas de blog y los productos de tienda, en particular, quedan organizados bajo un patrón de ruta que decide Wix, no el propietario del sitio. Se puede pulir el segmento final de la URL, pero no rediseñar libremente la arquitectura de carpetas como se haría en un sistema propio, y en un blog con mucho volumen o una tienda con taxonomía compleja esa rigidez sí llega a notarse.

El cuarto es la acumulación de aplicaciones. Cada app instalada no solo añade peso de carga: muchas inyectan su contenido mediante JavaScript del lado del cliente, así que esa información puede no formar parte real del HTML que un rastreador procesa primero. Un catálogo de reseñas cargado exclusivamente por una app externa corre el riesgo de no aportar el valor indexable que el propietario cree que está aportando.

Por dónde empezar si no eres desarrollador

Con el panel disponible y los límites claros, el orden de trabajo razonable para quien gestiona el sitio sin perfil técnico es este:

Este orden no es arbitrario: separa lo que depende solo de tiempo y criterio de lo que depende de la arquitectura de la plataforma, y conviene agotar lo primero antes de asumir que hace falta salir de Wix.

  • Revisar título y meta descripción de cada página que reciba tráfico o que debería recibirlo. Es el ajuste con más impacto directo y el que menos fricción técnica exige.
  • Limpiar los slugs que todavía arrastran identificadores automáticos o palabras sin sentido, sustituyéndolos por rutas legibles y descriptivas.
  • Verificar el sitemap en Google Search Console y confirmar que las páginas importantes están efectivamente indexadas, no solo publicadas.
  • Auditar las aplicaciones instaladas y desinstalar cualquiera que no esté cumpliendo una función activa. Cada app inactiva sigue cobrando en tiempo de carga aunque nadie la use.
  • Comprimir y redimensionar las imágenes antes de subirlas, en lugar de confiar en que la plantilla lo resuelva de forma automática.
  • Revisar el enlazado interno desde el propio editor visual: que las páginas relevantes se enlacen entre sí con texto ancla descriptivo, no solo "haz clic aquí".
  • Solo después de lo anterior, entrar a ajustar los datos estructurados y el canonical página por página, que suelen dar menos retorno cuando lo básico todavía no está resuelto.

Cuándo migrar tiene sentido, y cómo mapear las URLs

Migrar fuera de Wix es razonable cuando el sitio ha crecido más allá de lo que un constructor visual está pensado para sostener: un catálogo con miles de referencias, un blog cuyo volumen exige control granular sobre la estructura de categorías, o un negocio donde unos pocos cientos de milisegundos de carga tienen un impacto medible sobre la conversión y hace falta el control de caché y entrega que la plataforma no expone. También tiene sentido cuando hace falta una integración técnica concreta -un sistema de inventario propio, una lógica de precios compleja- que el ecosistema de apps de Wix no cubre de forma nativa.

Lo que no tiene sentido es migrar solo porque persiste la idea de que "Wix es malo para el SEO": si el problema real es de contenido o de enlazado, cambiar de plataforma no lo resuelve, solo lo traslada.

Cuando la migración sí está justificada, el paso que más se subestima -y el que más posicionamiento acumulado se juega- es el mapeo de URLs. La aproximación correcta es construir un listado completo de cada URL activa en Wix, con la ruta exacta -incluyendo los prefijos que la plataforma impone en blog y tienda- y su destino en la nueva estructura, para configurar una redirección 301 de uno a uno. Redirigir todo en bloque hacia la página de inicio, la salida fácil cuando el volumen de páginas asusta, tira a la basura buena parte del valor de enlazado acumulado. Conviene prestar atención especial a los segmentos que solo existían por convención de Wix, porque son los que con más facilidad se pierden si no se documentan antes de empezar el traslado.

El problema casi nunca es la plataforma

Después de repasar dónde ayuda Wix y dónde le pone techo al propietario del sitio, conviene cerrar con la parte menos cómoda: en la mayoría de los sitios de este tipo que no consiguen tracción en buscadores, cuando se investiga la causa real, la plataforma resulta no ser el factor limitante. Lo es el contenido -genérico, que no responde a lo que realmente busca quien escribe esa consulta, o directamente insuficiente- y lo es el enlazado, es decir, la ausencia casi total de otras páginas que apunten hacia el sitio. Ningún ajuste técnico, por bien ejecutado que esté, compensa esas dos carencias. Antes de decidir que el problema es Wix, vale la pena hacer el ejercicio honesto de revisar si el contenido realmente responde a la intención de búsqueda y si existe algún enlazado externo que sustente la autoridad del sitio. Casi siempre la respuesta está ahí, no en la plataforma.

Preguntas frecuentes

¿Sigue siendo cierto que Wix es malo para el SEO?

No, esa es la parte desactualizada de la conversación. En sus primeros años Wix tenía problemas reales de renderizado y de URLs móviles duplicadas, pero reconstruyó ese motor y hoy indexa y posiciona páginas con normalidad. Sigue teniendo límites propios de cualquier plataforma cerrada, pero no son los de hace una década.

¿Puedo usar Google Search Console con un sitio hecho en Wix?

Sí. Puedes verificar la propiedad del dominio, enviar el sitemap que Wix genera automáticamente y revisar cobertura de indexación, rendimiento y Core Web Vitals exactamente igual que con cualquier otro sitio.

¿Wix permite editar el archivo robots.txt?

Wix genera un robots.txt por defecto y permite añadir reglas personalizadas desde el propio panel de SEO, aunque no sustituye el archivo entero como se haría subiendo uno manualmente a un servidor propio.

¿Cuánto tarda Google en indexar una página nueva publicada en Wix?

No hay un plazo fijo ni Wix lo garantiza: depende de la frecuencia de rastreo que Google ya tenga asignada al dominio y de si la página se envía a indexar manualmente desde Search Console. Un sitemap actualizado ayuda, pero no fija un tiempo concreto.

¿Tiene sentido migrar de Wix a otra plataforma solo por SEO?

Solo si el motivo real es una limitación técnica que Wix no expone -control de caché, arquitectura de URLs, integraciones específicas-, no porque persista la idea de que Wix "no sirve para SEO". Si el problema es de contenido o de enlazado, cambiar de plataforma no lo resuelve.

Todos los artículos