Primero cuenta caminos de decisión, no páginas
No elijo un CMS por una plantilla bonita. Los problemas aparecen después: necesitas un segundo idioma, cambiar un canonical, poner un 301, conectar el CRM y averiguar por qué el formulario no se envió.
El error que eliminaría primero: Elegir la estructura por una plantilla en lugar de por el número de intenciones.
Qué preparar y qué resultado esperar
- Resultado: La estructura no bloquea el crecimiento ni obliga al visitante a buscar un servicio dentro de un lienzo universal.
- Cuenta servicios/productos, audiencias distintas, regiones, filtros, contenido y el número de páginas futuras.
- Guarda los datos de origen y los derechos de acceso aparte del resultado para poder verificar qué hizo la elección de estructura del sitio.
- Dibuja el recorrido de tres clientes típicos y comprueba si cada uno puede tener una URL y un CTA propios.
Encaja tres estructuras con cómo funciona de verdad el negocio
- Elige una landing page
Una landing encaja con un producto, una audiencia, un camino de decisión corto y pocas consultas autónomas. Construye secciones de problemas, prueba, condiciones y CTA.
Проверьте: Todo el escenario se puede completar sin una segunda página.
Если не сработало: Si aparecen servicios y preguntas distintas, muévelos a URLs separadas.
- Elige una estructura multipágina
Para varios servicios crea /services/ y una URL aparte para cada uno. Añade contactos, casos, FAQ y enlaces internos entre páginas relacionadas.
Проверьте: Cada página tiene su propia intención y un CTA con owner.
Если не сработало: No dividas un servicio por ciudad sin contenido local.
- Elige una tienda
Hace falta una tienda cuando hay catálogo, inventario, precios, variantes, carrito y compras repetidas. Describe filtros, categorías y reglas de indexación de antemano.
Проверьте: Un visitante puede encontrar un producto y entender disponibilidad/entrega.
Если не сработало: Con 3–5 productos usa una página de producto o un catálogo pequeño, no una plataforma pesada.
- Calcula el coste total de ownership
Suma soporte, contenido, integraciones, SEO, formularios, pagos y migración de datos. Un arranque barato con un mantenimiento manual caro no es un ahorro.
Проверьте: Hay un owner de los cambios tras el lanzamiento.
Если не сработало: Quita una función que nadie podrá mantener.
Una página de prueba antes de comprar
En cada plataforma crea `/test-service/` y comprueba: title, description, slug, canonical, noindex, JSON-LD, sitemap, redirección 301, formulario y GA4 sin doble conteo. Verifica la URL publicada, no la preview.
En WordPress abre `Settings → Reading` y `Settings → Permalinks`. En Webflow — `Pages → Page settings → SEO settings`. En Wix — `SEO & GEO → Tools and settings → SEO Settings`. En Tilda — la configuración SEO de la página y el `robots.txt` y `sitemap.xml` publicados.
curl -I https://example.com/test-service/
curl -s https://example.com/test-service/ | grep -Ei 'title|description|canonical|robots'Compruebo el coste de salida
Antes del lanzamiento pide export de contenido, imágenes y URLs, un backup, una tabla de redirecciones y la transferencia del dominio. Si cada cambio necesita un contratista, no es automáticamente una mala plataforma: solo suma tiempo interno y coste de soporte al TCO.
- El dominio y las cuentas de recuperación deben pertenecer a la empresa.
- Un sitio nuevo no debe cambiar todas las URLs sin un mapa de 301.
- El acceso a analítica y Search Console se verifica antes del lanzamiento.
Compruebo la ruta de emergencia, no solo el editor
Pide crear un backup, borrar una página de prueba, poner un 301, restaurar la página desde el backup y exportar el contenido. Si el soporte no sabe decir dónde vive el sitemap o cómo transferir el dominio, anótalo como riesgo de ownership.
Puntúa la plataforma sobre una página de servicio real y un formulario, no sobre una plantilla demo. Una hora de esa comprobación es más barata que una migración tras una caída de tráfico.
Cuándo necesitas landing, sitio o tienda
| Criterio | Pregunta | Buena señal |
|---|---|---|
| Entrada | ¿Qué entra exactamente en la elección de estructura del sitio? | Cuenta servicios/productos, audiencias distintas, regiones, filtros, contenido y el número de páginas futuras. |
| Acción | ¿Qué puede hacer el sistema por su cuenta? | Solo acciones prelistadas, sin acceso a toda la cuenta |
| Verificación | ¿Cómo sabes que el resultado es aceptable? | Dibuja el recorrido de tres clientes típicos y comprueba si cada uno puede tener una URL y un CTA propios. |
| Fallo | ¿Adónde van los casos poco claros? | Empieza con una estructura más pequeña y deja URLs limpias para servicios futuros en lugar de crear secciones “por si acaso”. |
Qué debe cambiar después de la configuración
La estructura no bloquea el crecimiento ni obliga al visitante a buscar un servicio dentro de un lienzo universal.
Cómo la estructura empieza a bloquear búsqueda y ventas
Elegir la estructura por una plantilla en lugar de por el número de intenciones.
Intentar meter cinco servicios en una sola landing.
Comprar una tienda sin owner del catálogo y del inventario.
No planificar la portabilidad del contenido y de las URLs.
Cuándo la elección del sitio no se puede hacer solo por presupuesto
Incorpora a un especialista si la elección afecta a un catálogo, varios mercados, migración de URLs o integraciones de pago y CRM.
Qué preguntarte antes de comprar una plantilla
¿Para quién es este enfoque de elección de estructura del sitio?
Una landing, un sitio multipágina y una tienda no se diferencian por el número de pantallas, sino por el número de intenciones, productos, reglas y escenarios de compra. Elige la estructura según cómo funciona el negocio.
¿Por dónde empiezas si todo sigue siendo manual?
Cuenta servicios/productos, audiencias distintas, regiones, filtros, contenido y el número de páginas futuras.
¿Cómo compruebas que el setup no te va a perjudicar?
Dibuja el recorrido de tres clientes típicos y comprueba si cada uno puede tener una URL y un CTA propios.
¿Y si el resultado no está claro?
Empieza con una estructura más pequeña y deja URLs limpias para servicios futuros en lugar de crear secciones “por si acaso”.
