Una Landing Page es una página diseñada alrededor de una acción principal.

Esa acción puede ser, por ejemplo:

• solicitar información;

• completar un formulario;

• consultar por WhatsApp;

• conocer un plan;

• solicitar una cotización;

• descargar un recurso;

• registrarse;

• visitar un producto;

• iniciar un proceso real disponible en la Página web.

La diferencia principal con una página institucional es el foco.

Una página institucional puede responder:

Quiénes somos
Qué hacemos
Servicios
Proyectos
Equipo
Contacto

Una Landing Page debería responder principalmente:

¿QUÉ ME PROPONEN?
↓
¿ES PARA MÍ?
↓
¿POR QUÉ ME CONVIENE?
↓
¿PUEDO CONFIAR?
↓
¿CÓMO FUNCIONA?
↓
¿QUÉ DEBO HACER AHORA?

Una Landing Page no es simplemente una página larga

Puedes tener:

12 Sections

y seguir sin tener una buena Landing Page.

La clave es que cada sección contribuya a:

UNA CONVERSIÓN PRINCIPAL

¿Qué vamos a construir?

Utilizaremos como modelo:

1. HERO
↓
2. PRUEBA DE CONFIANZA
↓
3. PROBLEMA / NECESIDAD
↓
4. BENEFICIOS
↓
5. CÓMO FUNCIONA
↓
6. CARACTERÍSTICAS / QUÉ INCLUYE
↓
7. PROYECTOS / RESULTADOS REALES
↓
8. TESTIMONIOS REALES
↓
9. OFERTA / PLANES SI CORRESPONDE
↓
10. FAQ / OBJECIONES
↓
11. CTA PRINCIPAL
↓
12. FORMULARIO / CONTACTO

No todas las Landings necesitan los 12 puntos.

Puedes:

• eliminar;

• reorganizar;

• combinar;

según la propuesta.

Primera regla

Toda Landing Page debe tener un objetivo principal definido antes de comenzar a diseñarla.

Paso 1. Define la conversión principal

Completa esta frase:

El objetivo principal de esta Landing Page es que el visitante:
____________________________________________

Por ejemplo:

solicite una demostración

O:

complete un formulario de consulta

O:

vea los planes disponibles

O:

se comunique por WhatsApp

No escribas:

que conozca la empresa, vea productos, siga Instagram,
lea el blog, complete un formulario, se suscriba
y además nos contacte

como objetivo principal.

Eso representa múltiples objetivos

Una Landing necesita prioridad.

Segunda regla

UNA LANDING
→ UNA ACCIÓN PRINCIPAL

Puede haber acciones secundarias,

pero deben apoyar a la principal.

Paso 2. Define qué ocurre realmente después del CTA

Supongamos que tu Button dice:

SOLICITAR DEMOSTRACIÓN

Pregunta:

¿qué sucede realmente?

Puede ser:

abre formulario

O:

lleva a página de agenda

O:

abre WhatsApp

No debería decir:

RESERVAR DEMOSTRACIÓN

si lo único que ocurre es:

enviar una consulta sin confirmar horario

Tercera regla

La promesa del CTA debe coincidir exactamente con el flujo real.

Ejemplos correctos

SOLICITAR INFORMACIÓN
→ formulario de consulta

CONTACTAR POR WHATSAPP
→ WhatsApp

VER PLANES
→ página o Section de planes

DESCARGAR CATÁLOGO
→ descarga real del archivo

Ejemplos problemáticos

COMPRAR AHORA
→ formulario de contacto

COMENZAR GRATIS
→ página de pago

RESERVAR
→ WhatsApp para consultar disponibilidad

Paso 3. Define el público

Completa:

Esta Landing está dirigida principalmente a:
____________________________________________

Por ejemplo:

empresas que necesitan crear su primera Página web

O:

clientes que necesitan integrar productos de proveedores

O:

negocios que necesitan solicitar un presupuesto

Cuanto más claro sea el público,

más claro puede ser:

• Hero;

• beneficio;

• CTA.

No necesitas excluir artificialmente a otros visitantes

Pero debes saber:

a quién estás hablando primero

Paso 4. Define la propuesta

Una fórmula sencilla:

AYUDAMOS A [PÚBLICO]
A [RESULTADO / NECESIDAD]
MEDIANTE [SOLUCIÓN REAL]

Por ejemplo:

Una plataforma para empresas que necesitan gestionar
su Página web y sus herramientas digitales desde un mismo entorno.

si describe correctamente la propuesta.

Evita:

La solución definitiva que cambiará tu negocio para siempre.

Es espectacular,

pero no explica:

qué hace

Paso 5. Define las objeciones antes de diseñar

Pregunta:

¿Qué puede impedir que una persona avance?

Por ejemplo:

No entiendo cómo funciona.

No sé si es para mi negocio.

No conozco el precio.

No sé qué incluye.

No sé si puedo confiar.

No sé cuánto tarda.

La Landing debe resolver estas dudas

mediante:

• beneficios;

• características;

• proceso;

• proyectos;

• testimonios;

• precios;

• FAQ.

No necesitas una FAQ de 20 preguntas

si puedes resolver la duda antes dentro del contenido.

Paso 6. Reúne información real

Antes de abrir el Editor prepara:

Propuesta
Beneficios
Características
Proceso
Precios si corresponde
Proyectos
Testimonios
FAQ
CTA
Formulario

No inventes para llenar espacios

Si no tienes testimonios:

no agregues Testimonios

Si no puedes publicar clientes:

no inventes logos

Si no tienes una métrica:

no inventes Counter

Si no existe una promoción:

no inventes urgencia

Paso 7. Define la arquitectura

Nuestro caso práctico utilizará:

HERO
↓
CONFIANZA
↓
NECESIDAD
↓
BENEFICIOS
↓
CÓMO FUNCIONA
↓
QUÉ INCLUYE
↓
PROYECTOS
↓
TESTIMONIOS
↓
FAQ
↓
CTA
↓
FORMULARIO

Cada Section debe responder una pregunta

Hero:

¿Qué me ofrecen?

Confianza:

¿Por qué debería seguir leyendo?

Necesidad:

¿Entienden mi situación?

Beneficios:

¿Qué gano con esta solución?

Proceso:

¿Cómo funciona?

Características:

¿Qué incluye?

Proyectos:

¿Pueden demostrar experiencia?

Testimonios:

¿Qué dicen otras personas reales?

FAQ:

¿Qué dudas me quedan?

CTA:

¿Qué hago ahora?

Formulario:

¿Cómo avanzo?

Paso 8. Crea la Landing desde una sección nueva cuando corresponda

Cuando estés construyendo una página/sección personalizada:

puedes utilizar el Editor de bloques para desarrollar toda la composición.

Si utilizas una página fija de Waclis

recuerda que existen posiciones editables específicas.

Header y Footer:

NO se editan desde el Editor de bloques

Esto es especialmente relevante en una Landing

porque muchas Landings reducen la navegación.

Paso 9. Landing con navegación vs Landing sin navegación

Existen dos enfoques.

Con navegación normal

El Header del sitio continúa mostrando:

• logo;

• menú.

Puede ser apropiado cuando:

• la Landing forma parte natural del sitio;

• quieres que el visitante explore.

Con navegación reducida

En algunas campañas puede ser deseable reducir:

distracciones

Pero recuerda:

el Header no puede modificarse desde el Editor de bloques.

Si necesitas cambiar u ocultar elementos del Header:

eso corresponde a la plantilla o herramientas generales del sitio,

no a este bloque editable.

No recrees un Header falso dentro de la Landing para compensarlo.

Paso 10. No asumas que quitar navegación aumenta automáticamente conversiones

Depende del contexto.

Por ejemplo

una persona puede querer:

• conocer la empresa;

• revisar productos;

• comprobar confianza.

Eliminar todas las salidas puede resultar contraproducente.

La decisión debe responder a:

objetivo
+
tipo de tráfico
+
necesidad del visitante

Paso 11. Construye el Hero

El Hero es la sección más importante para explicar:

QUÉ
+
PARA QUIÉN
+
POR QUÉ
+
QUÉ HACER

Una estructura sólida:

EYEBROW
↓
H1
↓
PARAGRAPH
↓
CTA PRINCIPAL
↓
CTA SECUNDARIO OPCIONAL
↓
IMAGE / VISUAL

Por ejemplo:

GESTIÓN DIGITAL

Todo lo que necesitas para administrar tu presencia online

Centraliza diferentes herramientas y gestiona tu Página web
desde un único entorno.

[ CONOCER PLANES ]    Solicitar información →

Utiliza únicamente información real de tu propuesta.

Paso 12. El Hero debe poder entenderse sin leer toda la página

Prueba:

solo H1
+
Paragraph
+
CTA

Pregunta:

¿entiendo qué me están ofreciendo?

Si no:

el Hero es demasiado abstracto.

Ejemplo débil

El futuro de tu empresa empieza hoy

Puede servir como frase secundaria,

pero no explica la propuesta.

Paso 13. Utiliza un único H1 principal

Normalmente:

H1
→ propuesta principal de la Landing

Las Sections posteriores:

H2

Y elementos internos:

H3

No utilices varios H1 simplemente para hacer títulos grandes.

Paso 14. CTA principal del Hero

Debe coincidir con la conversión definida al comienzo.

Si el objetivo es:

solicitar información

puede ser:

[ SOLICITAR INFORMACIÓN ]

No cambies a:

[ COMPRAR AHORA ]

solo porque parece más comercial.

Paso 15. CTA secundario

Puede ser:

Ver cómo funciona ↓

O:

Ver planes →

Debe ayudar a quienes todavía no están listos para la acción principal.

No debería competir con ella.

Paso 16. Link vs Html Button

Si el CTA navega:

utiliza:

Link

Puede tener apariencia visual de Button.

Si utilizas Html Button:

recuerda que un Button HTML no crea automáticamente navegación.

Para:

ir a otra Section

o:

abrir otra página

Link suele ser la opción adecuada.

Paso 17. Visual del Hero

Puedes utilizar:

• Image;

• captura;

• producto;

• ilustración;

• video cuando realmente aporte.

No agregues:

imagen genérica de personas señalando una pantalla

si no ayuda a comprender la solución.

Para un producto digital:

una captura real puede explicar mucho más.

Paso 18. Background Image

También puedes utilizar:

Section
→ Background Image
→ Overlay

Pero recuerda:

Background:

puede recortarse

No coloques información esencial dentro de la imagen.

Paso 19. Hero responsive

Desktop:

[ TEXTO  ][ VISUAL ]

Mobile:

TEXTO
CTA
VISUAL

El contenido principal debería aparecer antes que un visual puramente decorativo.

No permitas que mobile comience con:

gran imagen
↓
gran imagen
↓
recién después H1

sin una razón.

Paso 20. Segunda Section: confianza temprana

Después del Hero puede ser útil mostrar una señal de confianza.

Por ejemplo:

• clientes reales;

• logos reales;

• proyectos;

• certificaciones reales;

• datos verificables.

También puede ser simplemente:

Utilizado por empresas de...

solo si puedes sostener la afirmación.

No necesitas inventar una barra de logos.

Si no tienes contenido de confianza adecuado:

puedes continuar directamente con:

Beneficios

Paso 21. Logos de clientes

Utiliza únicamente:

marcas con una relación real

y que corresponda mostrar.

No utilices:

• Google;

• Microsoft;

• Nike;

• Coca-Cola;

como decoración si no existe relación real.

Mostrar un logo puede implicar:

“trabajamos con esta marca”

Debe ser verdadero.

Paso 22. Estadísticas

Por ejemplo:

500 clientes

O:

10 años

Solo si:

• el dato es real;

• está correctamente definido.

No conviertas:

algunos clientes

en:

+10.000 clientes

para mejorar visualmente una Section.

Paso 23. Counter

Counter puede ser apropiado para datos reales.

Pero:

COUNTER
≠
VERIFICACIÓN

El componente muestra un número.

Eres responsable de que:

el número sea correcto

Paso 24. Tercera Section: problema o necesidad

Una Landing puede ayudar a que el visitante se reconozca en la situación.

Por ejemplo:

¿Gestionas diferentes herramientas por separado?

Después:

Centralizar determinadas tareas puede simplificar...

si corresponde a la solución real.

No exageres el problema.

Evita:

Si no utilizas nuestro producto, tu empresa está perdiendo dinero todos los días.

si no puedes sostenerlo.

Paso 25. No conviertas el problema en miedo artificial

Una Landing puede ser persuasiva sin:

• amenazas;

• urgencia falsa;

• catastrofismo.

Explica:

situación real
→ solución real

Paso 26. Problema antes de beneficios

La secuencia puede ser:

PROBLEMA
↓
SOLUCIÓN
↓
BENEFICIOS

Pero si tu público ya conoce perfectamente el problema:

puedes omitir esa Section.

No necesitas enseñar al visitante algo que ya sabe.

Paso 27. Cuarta Section: beneficios

Ahora respondemos:

¿POR QUÉ ME INTERESA?

Utiliza:

Font Icon / Svg Icon
+
H3
+
Paragraph

Por ejemplo:

[ ICONO ]

Gestiona desde un solo lugar

Centraliza diferentes tareas dentro del entorno disponible.

si describe la funcionalidad real.

Paso 28. Beneficio ≠ característica

Característica:

Editor visual

Beneficio:

Puedes realizar determinados cambios de contenido mediante herramientas visuales.

Una Landing debe traducir:

FUNCIÓN
→ UTILIDAD

Paso 29. No inventes resultados comerciales

No escribas:

Aumenta tus ventas

solo porque existe:

editor visual

No existe una relación garantizada.

Utiliza beneficios directos que puedan sostenerse.

Paso 30. Beneficios 3 → 2 → 1

Una buena estructura puede ser:

Desktop:

[ A ][ B ][ C ]

Tablet:

[ A ][ B ]

[ C ]

Mobile:

A

B

C

Para seis:

3
↓
2
↓
1

Paso 31. CTA intermedio

Después de explicar los beneficios

puede existir un CTA.

Por ejemplo:

[ SOLICITAR INFORMACIÓN ]

No tiene que ser diferente del CTA del Hero.

De hecho:

repetir la acción principal en puntos lógicos puede ayudar.

Cuarta regla

Repetir el CTA principal es válido. Cambiar de objetivo en cada sección no lo es.

Hero:

SOLICITAR INFORMACIÓN

Beneficios:

SOLICITAR INFORMACIÓN

Final:

SOLICITAR INFORMACIÓN

Todos conducen a la misma acción.

Esto mantiene consistencia.

Paso 32. No repitas el CTA después de cada párrafo

Una Landing puede volverse:

CTA
texto
CTA
texto
CTA
Card
CTA
texto
CTA

Eso puede resultar invasivo.

Utiliza puntos de decisión naturales.

Paso 33. Quinta Section: cómo funciona

Ahora respondemos:

¿QUÉ OCURRE SI AVANZO?

Puedes utilizar:

• Timeline;

• Cards;

• Grid;

• texto + imagen.

Por ejemplo:

1
Elige una opción

2
Configura...

3
Comienza...

Solo describe el proceso real.

Paso 34. No inventes un proceso más sencillo de lo que realmente es

Si requiere:

evaluación
+
configuración
+
aprobación

no escribas:

1 clic y listo

salvo que realmente funcione de esa forma.

La Landing debe reducir incertidumbre,

no ocultar pasos importantes.

Paso 35. Proceso con tres pasos

Una estructura muy clara:

[ 1 ]      [ 2 ]      [ 3 ]

Paso A     Paso B     Paso C

Texto      Texto      Texto

Mobile:

1
Paso A

2
Paso B

3
Paso C

Timeline también puede ser apropiado

si existe una secuencia más extensa.

Paso 36. Características / qué incluye

Beneficios responden:

¿POR QUÉ ME IMPORTA?

Características:

¿QUÉ RECIBO / QUÉ TIENE?

Por ejemplo:

Incluye:
- [...]
- [...]
- [...]

No repitas literalmente Beneficios.

Paso 37. Puedes utilizar una List

No todo necesita Cards.

Por ejemplo:

Incluye

✓ Función A
✓ Función B
✓ Función C
✓ Función D

Puede ser más directa.

Paso 38. No conviertas una lista simple en 12 Cards

El componente debe ayudar a:

comprender

No solo a:

decorar

Paso 39. Diferencia entre “incluye” y “puede incluir”

Si una función depende de:

• plan;

• configuración;

• integración;

no la presentes como:

incluida siempre

si no es así.

Utiliza una descripción precisa.

Paso 40. Sección de producto visual

Puedes intercalar:

TEXT | IMAGE

Por ejemplo:

Gestiona...
[ captura real ]

Después:

[ captura ]
Personaliza...

Desktop puede alternar.

Mobile debe conservar:

texto
↓
visual

cuando ese sea el orden lógico.

Paso 41. No utilices capturas falsas

Si muestras un software:

utiliza:

• interfaz real;

• mockup claramente ilustrativo;

según corresponda.

No inventes funcionalidades dentro de una pantalla generada

y luego las presentes como existentes.

Paso 42. Proyectos / casos

Ahora respondemos:

¿PUEDEN DEMOSTRAR EXPERIENCIA?

Puedes utilizar:

• Portfolio;

• Cards;

• Gallery.

Por ejemplo:

ALGUNOS PROYECTOS

[ A ][ B ][ C ]

Solo proyectos reales.

Paso 43. Caso de estudio breve

Una Card puede incluir:

PROYECTO
↓
QUÉ SE HIZO
↓
RESULTADO REAL OPCIONAL

No necesitas inventar:

+157% conversiones

Si no existe una métrica:

describir el trabajo es suficiente.

Paso 44. Testimonios

Los testimonios pueden ayudar a responder:

¿OTRAS PERSONAS TUVIERON UNA BUENA EXPERIENCIA?

Pero solo utiliza:

• comentarios reales;

• nombres reales cuando corresponda;

• empresas reales cuando corresponda.

No utilices IA para inventar:

“Es increíble, multiplicamos nuestras ventas.”
— Juan, Empresa X

Si no existe:

elimina la Section.

Paso 45. Testimonio sin nombre

Si por privacidad un cliente no puede identificarse,

puedes utilizar una atribución más general cuando corresponda.

Pero no hagas pasar:

un texto inventado

por:

testimonio anónimo

Debe seguir siendo real.

Paso 46. Pricing / oferta

Si la Landing tiene:

• planes;

• precios;

• paquetes;

puedes utilizar:

Tabla de precios

Pero solo si:

los precios y condiciones son correctos

Paso 47. No inventes un precio tachado

Evita:

ANTES $100.000
AHORA $49.999

si ese precio anterior nunca existió.

Tampoco:

50 % OFF

sin una promoción real.

Paso 48. Plan destacado

Puedes marcar:

RECOMENDADO

si existe un criterio real para hacerlo.

No utilices:

MÁS ELEGIDO

si no tienes datos.

“Recomendado” puede ser una decisión editorial.

“Más elegido” afirma un comportamiento real de clientes.

No son equivalentes.

Paso 49. Precio y condiciones

Si un valor:

no incluye impuestos

o depende de condiciones,

debe comunicarse según corresponda.

No ocultes información esencial alrededor de la oferta.

Paso 50. Precio dinámico

No asumas que un texto en un Paragraph:

$99.999

se actualizará automáticamente.

Es contenido manual,

salvo que exista una funcionalidad específica que lo haga.

Si cambia:

debes mantenerlo actualizado.

Paso 51. CTA del plan

Debe coincidir con el flujo.

Por ejemplo:

CONTRATAR

solo si inicia realmente un proceso de contratación apropiado.

Si solo abre:

consulta

puede ser:

CONSULTAR POR ESTE PLAN

Paso 52. FAQ

La FAQ es especialmente útil cerca de la decisión.

Puede resolver objeciones como:

¿Qué incluye?
¿Necesito conocimientos técnicos?
¿Cómo se realiza...?
¿Qué ocurre después?

Siempre con respuestas reales.

Paso 53. FAQ no debe esconder condiciones importantes

Si existe una limitación significativa:

no la escondas deliberadamente en:

último acordeón

La información esencial de la propuesta debe ser clara.

Paso 54. Acordeón para FAQ

Puedes utilizar:

• sección Preguntas frecuentes;

• Acordeones;

• Accordeon.

Mantén:

una pregunta
↔
una respuesta

Revisa:

• IDs;

• relaciones;

especialmente después de clonar.

Paso 55. FAQ no es un lugar para SEO de relleno

No agregues:

30 preguntas

solo para tener más texto.

Utiliza dudas reales.

Paso 56. CTA final

Después de resolver:

beneficios
+
proceso
+
confianza
+
objeciones

llega el momento de:

ACTUAR

Por ejemplo:

¿Quieres conocer qué opción se adapta a tu proyecto?

[ SOLICITAR INFORMACIÓN ]

El CTA final debería ser coherente con el Hero.

No cambies de:

Solicitar información

a:

Comprar

sin que el flujo haya cambiado.

Paso 57. CTA centrado

Puede utilizar:

Heading
Paragraph
Link principal

Sobre:

• Background sólido;

• Background Image + Overlay.

Mantén alta visibilidad mediante:

CONTRASTE
+
ESPACIO

No necesitas:

Button que rebota permanentemente

Paso 58. Formulario final

Si la conversión principal es:

enviar una consulta

puedes incorporar el Form directamente.

Ejemplo:

¿Quieres recibir más información?

Nombre
Email
Empresa
Mensaje

[ SOLICITAR INFORMACIÓN ]

Mantén los campos mínimos necesarios.

Paso 59. Formulario corto vs formulario largo

Formulario corto:

Nombre
Email
Mensaje

Menos fricción.

Formulario más completo:

Nombre
Email
Empresa
Teléfono
Motivo
Mensaje

Más información previa.

Ninguno es automáticamente mejor.

Pregunta:

¿Qué información necesito antes de poder responder de manera útil?

Paso 60. No solicites datos que puedes obtener después

Si no necesitas:

dirección postal

para responder una primera consulta:

probablemente no hace falta.

Paso 61. No pidas información sensible

No solicites mediante una Landing genérica:

• contraseña;

• token;

• credenciales;

• información sensible innecesaria.

Paso 62. Form visible ≠ Form funcional

Esto vuelve a ser crítico.

NOMBRE
EMAIL
[ ENVIAR ]

puede verse perfecto

y no estar conectado a ningún procesamiento.

Debes realizar una prueba real.

Paso 63. Si partes de un Form funcional

Conserva:

• Form;

• Names;

• IDs cuando participan de relaciones;

• Types;

• atributos;

• control de envío.

No cambies la lógica para modificar:

• Border;

• Padding;

• Typography.

Paso 64. Asterisco ≠ required

Mostrar:

Email *

no crea automáticamente validación.

Debes comprobar:

comportamiento funcional

Paso 65. Button de envío

No lo reemplaces por:

Link

si el Button está encargado de enviar el Form.

Link:

navega

Submit:

participa en el envío

Son funciones diferentes.

Paso 66. Conversión por WhatsApp

Si el objetivo principal es WhatsApp:

puedes repetir:

CONTACTAR POR WHATSAPP

en:

• Hero;

• después de beneficios;

• CTA final.

Todos deberían utilizar:

el destino correcto

Paso 67. No llames “Comprar” a WhatsApp

Abrir una conversación:

≠ completar una compra

Utiliza:

CONSULTAR POR WHATSAPP

o:

HABLAR POR WHATSAPP

cuando describan mejor el flujo.

Paso 68. Conversión por teléfono

Puede ser apropiada para determinados servicios.

Utiliza un Link adecuado.

Y un texto claro:

LLAMAR

No necesitas mostrar:

un formulario largo

si la acción principal real es la llamada.

Paso 69. Conversión por agenda

Si el flujo real permite:

reservar un horario

el CTA puede reflejarlo.

Pero si solo permite:

solicitar que alguien contacte

no digas:

RESERVAR AHORA

Paso 70. Links internos

Puedes utilizar IDs:

#beneficios
#planes
#contacto

Por ejemplo:

Hero:

Ver planes ↓

apunta a:

#planes

IDs deben ser:

• únicos.

Paso 71. CTA a formulario interno

Puedes utilizar:

#contacto

De esta manera:

SOLICITAR INFORMACIÓN

desplaza al formulario final.

Siempre verifica que:

id="contacto"

exista una sola vez.

Paso 72. No clones IDs

Si clonas una Section con:

id="beneficios"

cambia o elimina el ID en la copia.

Dos IDs iguales pueden producir:

• enlaces ambiguos;

• CSS inesperado.

Paso 73. Navigator

Una Landing extensa puede tener:

BODY
├── Hero
├── Trust
├── Problem
├── Benefits
├── Process
├── Features
├── Portfolio
├── Testimonials
├── Pricing
├── FAQ
├── CTA
└── Form

Utiliza Navigator como:

MAPA DE LA PÁGINA

No dependas únicamente de hacer scroll.

Paso 74. Nombra conceptualmente las Sections

Si utilizas Classes:

landing-hero
landing-trust
landing-benefits
landing-process
landing-proof
landing-faq
landing-cta
landing-form

Esto facilita:

• CSS;

• mantenimiento.

No necesitas estos nombres exactos.

Paso 75. Crea un sistema de Classes reutilizables

Por ejemplo:

landing-section-title
landing-section-description
landing-primary-cta
landing-secondary-cta

Así puedes mantener:

• Typography;

• Buttons;

• espacios;

coherentes.

Paso 76. No utilices ID para todos los estilos

Evita:

#hero-title
#benefits-title
#process-title
#faq-title

si todos comparten el mismo diseño.

Utiliza Class.

Paso 77. Linked styles

Una Landing completa tendrá muchos elementos compartidos.

Si cambias un CTA principal

y cambian todos:

puede ser deseado.

Por eso:

antes de modificar:

revisa Linked styles

Si un CTA necesita una variante:

agrega una Class adicional.

Paso 78. Ritmo de Backgrounds

Puedes estructurar:

Hero
fondo fuerte

Trust
blanco

Problem
gris suave

Benefits
blanco

Process
gris suave

Proof
blanco

FAQ
gris suave

CTA
fondo fuerte

Form
blanco

Es solo un ejemplo.

No conviertas la página en:

12 colores diferentes

Paso 79. Tampoco hagas todas las Sections idénticas

Puedes alternar:

Hero
↓
logos
↓
texto + imagen
↓
icon grid
↓
timeline
↓
portfolio
↓
quotes
↓
accordion
↓
CTA

El tipo de contenido genera variedad.

Paso 80. Padding como sistema

Puedes trabajar con:

Section normal
→ 72–96px desktop

como referencia.

Mobile:

40–56px

Son referencias,

no valores obligatorios.

Hero y CTA pueden necesitar otras proporciones.

Paso 81. No uses Full Height en cada Section

Eso puede transformar una Landing de:

10 Sections

en:

10 pantallas completas

Puede volverse interminable.

Utiliza:

Auto
+
Padding

como opción general.

Paso 82. Responsive completo

No diseñes cada Section aisladamente.

Desktop:

múltiples columnas

Tablet:

2 columnas
o apilado

Mobile:

recorrido vertical

La Landing mobile puede ser muy extensa.

Por eso:

la prioridad y la edición del contenido se vuelven fundamentales.

Paso 83. No ocultes media Landing en mobile

No uses:

Hide based on device

para eliminar:

• beneficios;

• confianza;

• FAQ;

solo porque la página quedó larga.

Si una Section no es necesaria en mobile:

pregunta si realmente era necesaria en desktop.

Paso 84. Puedes ocultar recursos decorativos

Por ejemplo:

una ilustración puramente ornamental

podría ocultarse

si:

• no contiene información;

• mejora la experiencia mobile.

Pero no ocultes:

contenido esencial

Paso 85. Orden lógico mobile

Una composición desktop:

IMAGE | TEXT

puede necesitar mobile:

TEXT
IMAGE

Especialmente si el texto introduce el concepto.

Planifica antes.

Paso 86. Tablet

Presta especial atención a:

3 columnas

Muchas veces:

3 desktop
→ 2 tablet
→ 1 mobile

es más cómodo.

No reduzcas todo para conservar tres.

Paso 87. CTA mobile

Un CTA largo:

SOLICITAR UNA DEMOSTRACIÓN PERSONALIZADA

puede quedar en varias líneas.

Evalúa una versión más clara:

SOLICITAR DEMOSTRACIÓN

No necesita decir toda la propuesta.

Paso 88. CTA principal consistente

No utilices:

Hero:

COMENZAR

Benefits:

QUIERO ESTO

Pricing:

COMPRAR

Final:

CONTACTAR

si todos llevan al mismo formulario.

Mejor:

SOLICITAR INFORMACIÓN

de forma consistente

cuando esa sea realmente la acción.

Paso 89. La redacción puede variar ligeramente

Por ejemplo:

SOLICITAR INFORMACIÓN

Y:

HABLAR CON UN ASESOR

si ambas acciones representan canales distintos y reales.

Pero debe ser intencional.

Paso 90. Evita CTA genéricos

No:

CLIC AQUÍ

Mejor:

VER PLANES

O:

CONTACTAR

Paso 91. No simules escasez

Evita:

SOLO QUEDAN 3 CUPOS

si no existe un mecanismo real para verificarlo.

También:

OFERTA TERMINA EN 05:32

si el contador reinicia al recargar.

La urgencia falsa puede dañar la confianza.

Paso 92. Urgencia real

Si una promoción realmente vence:

31 de agosto

puedes comunicarlo.

Pero debes actualizar la página al finalizar.

Contenido temporal necesita mantenimiento.

Paso 93. Countdown

No asumas que:

Counter

es un temporizador.

Counter es otro componente.

Si necesitas un Countdown real:

debe existir una funcionalidad específica.

No simules uno con números estáticos.

Paso 94. Promociones

No utilices:

-50%

sin una promoción real.

Y el precio de referencia debe ser correcto.

La Landing puede convertir sin tácticas artificiales.

Paso 95. Prueba social

Puede utilizar:

• Testimonios;

• Portfolio;

• Logos;

• métricas verificables.

No necesitas usar los cuatro.

Selecciona:

la evidencia disponible

Paso 96. No repitas la misma prueba

Por ejemplo:

logos en Hero
logos después del Hero
logos antes del CTA
logos en Footer

Puede resultar redundante.

Paso 97. Imágenes

Cada Image debe tener una función.

Pregunta:

¿AYUDA A ENTENDER?
¿GENERA CONTEXTO?
¿DEMUESTRA ALGO?

Si solo ocupa espacio:

evalúa retirarla.

Paso 98. Images de stock

Pueden utilizarse cuando corresponda.

Pero no deben hacer parecer que:

las personas fotografiadas
=
clientes reales / equipo real

si no es así.

Evita ambigüedad.

Paso 99. Performance

Una Landing puede acumular:

• Hero Image;

• videos;

• seis proyectos;

• mapas;

• embeds;

• Lottie.

Pregunta:

¿todos estos recursos ayudan a convertir o comprender?

Si no:

reduce.

Paso 100. Video

Puede ser muy útil para explicar una propuesta compleja.

Utiliza:

Embed Video

cuando el visitante necesita:

• reproducir;

• controlar.

No utilices Background Video como sustituto de una explicación importante.

Paso 101. Lottie

Puede aportar movimiento.

Pero no debería competir con:

• CTA;

• propuesta.

Si ya tienes:

Hero animado
+
Cards animadas
+
Lottie
+
video

puede ser demasiado.

Paso 102. Animate on scroll

Utiliza moderadamente.

Una estrategia:

Section entra suavemente

No:

cada elemento con una animación distinta

Paso 103. No retrases CTA

El CTA debe estar disponible.

No configures:

Delay 5 segundos

Paso 104. Hover

El Hover:

refuerza

No debería:

ocultar o revelar información esencial

Mobile debe funcionar sin él.

Paso 105. Formularios y Focus

Focus es especialmente importante.

No elimines:

la señal de campo activo

por estética.

Paso 106. Prueba la conversión de principio a fin

Ejemplo:

ANUNCIO / ENLACE
↓
LANDING
↓
CTA HERO
↓
FORMULARIO
↓
ENVIAR
↓
CONFIRMACIÓN
↓
RECEPCIÓN

No pruebes solamente:

el Button

Prueba el recorrido completo.

Paso 107. CTA interno

Si Hero apunta al formulario:

href="#contacto"

Comprueba:

1. clic;

2. desplazamiento;

3. formulario visible;

4. campo utilizable.

Paso 108. Envío del Form

Prueba:

vacío

Luego:

email inválido

Luego:

datos válidos

Comprueba:

recepción real

Paso 109. CTA WhatsApp

Haz clic desde:

• desktop;

• mobile;

cuando sea posible.

Comprueba:

• número;

• mensaje;

• destino.

Paso 110. CTA externo

Si lleva a:

• calendario;

• checkout;

• otra plataforma;

prueba todo el flujo.

No asumas que:

la URL abre

significa:

la conversión funciona

Paso 111. Pricing

Si el CTA lleva a compra:

prueba:

plan correcto
↓
precio correcto
↓
flujo correcto

Especialmente después de clonar Cards.

Paso 112. Error típico de planes clonados

Plan A:

Estandar
/checkout/estandar

Copia:

Premium
/checkout/estandar

Visualmente:

correcto.

Funcionalmente:

incorrecto.

Revisa URLs.

Paso 113. Error típico de CTA repetido

Hero:

SOLICITAR INFORMACIÓN
→ #contacto

CTA intermedio:

SOLICITAR INFORMACIÓN
→ #

CTA final:

SOLICITAR INFORMACIÓN
→ /otra-pagina

La misma acción produce tres recorridos diferentes.

Revisa consistencia.

Paso 114. Revisión de Navigator

Busca:

• Sections vacías;

• Card duplicada;

• CTA duplicado;

• IDs repetidos.

Una Landing larga puede acumular errores sin que se noten visualmente.

Paso 115. Sections vacías

Puede quedar:

Section
└── Container vacío

Eso genera:

• espacio;

• Padding;

sin contenido.

Elimínala si no cumple función.

Paso 116. Clonar Sections

Es útil para:

• beneficios;

• texto + imagen;

• CTA.

Pero revisa:

TEXT
IMAGE
ALT
LINK
URL
ID

No clones contenido sin una auditoría.

Paso 117. Linked styles

Una Landing utiliza muchos patrones compartidos.

Esto puede ser positivo.

Por ejemplo:

landing-primary-cta

en:

• Hero;

• mitad;

• final.

Un cambio puede mantener todos consistentes.

Paso 118. Pero cuidado con modificaciones accidentales

Si quieres modificar solamente:

CTA final

y cambian los tres:

revisa el selector compartido.

Puedes agregar una variante:

landing-primary-cta landing-primary-cta-light

Paso 119. CSS localizado

Utiliza:

.landing-page .landing-primary-cta {
    ...
}

cuando dispongas de una Class raíz apropiada.

No:

a {
}

Paso 120. Class raíz

Si puedes asignar una Class a un contenedor principal o Sections relacionadas,

puedes utilizar un scope consistente.

Por ejemplo:

landing-page

Pero no la agregues sin comprobar dónde corresponde.

Paso 121. No modifiques .container globalmente

Evita:

.container {
    max-width: 1600px;
}

Puede afectar todo el sitio.

Utiliza:

• Container width;

• Classes propias.

Paso 122. No modifiques .row globalmente

Evita:

.row {
    align-items:center;
}

Puede alterar:

• pricing;

• Form;

• proyectos.

Paso 123. No modifiques .card globalmente

Una Landing puede contener Cards de:

• benefits;

• projects;

• pricing.

Si haces:

.card {
    border-radius:30px;
}

todas cambiarán.

Tal vez no quieres eso.

Utiliza scope específico.

Paso 124. No modifiques h2 globalmente

Puedes crear:

landing-section-title

Y aplicar:

Typography

mediante esa Class.

Paso 125. No modifiques button globalmente

Puede afectar:

• Form;

• Accordion;

• otros componentes.

Para navegación:

utiliza Link con Class propia.

Paso 126. Bootstrap

Waclis utiliza:

Bootstrap 4

No agregues:

• Bootstrap 5;

• Tailwind;

• otro sistema Grid;

solo para construir una Landing.

Aprovecha:

• Grid Row;

• Components;

• CSS localizado.

Paso 127. IA y Bootstrap

Cuando pidas CSS o HTML a ChatGPT, Claude o Gemini:

indica:

Waclis utiliza Bootstrap 4.

Esto reduce el riesgo de recibir:

• Classes;

• sintaxis;

pensadas para otra versión.

Paso 128. No le pidas a IA que reescriba toda la página

Un prompt como:

Mejora todo este HTML

puede generar:

• estructura nueva;

• IDs nuevos;

• Classes nuevas;

• dependencias nuevas.

Mejor:

Modifica únicamente esta Section.
No cambies estructura externa.

Paso 129. No permitas que IA invente testimonios

Prompt peligroso:

Crea tres testimonios convincentes.

Eso genera contenido ficticio.

Mejor:

Tengo estos tres testimonios reales.
Acórtalos sin cambiar el significado.

Paso 130. No permitas que IA invente estadísticas

No:

dame cuatro métricas impactantes

Mejor:

Estos son mis datos verificables.
Ayúdame a decidir cuáles son relevantes.

Paso 131. No permitas que IA invente funcionalidades

Si le dices:

haz que mi producto suene más completo

puede agregar características inexistentes.

Indica:

No inventes ninguna funcionalidad.

Paso 132. No copies JavaScript generado sin entenderlo

Especialmente si:

• envía formularios;

• procesa pagos;

• agrega tracking;

• manipula datos.

Una Landing no debería necesitar código arbitrario para resolver su layout.

Paso 133. No coloques secretos en prompts o frontend

Evita compartir:

• claves privadas;

• tokens;

• contraseñas.

Y no los insertes en:

• HTML;

• CSS;

• JavaScript del navegador.

Paso 134. CSS vs HTML

Si necesitas:

cambiar espacio

utiliza:

• Estilo;

• CSS.

No reescribas HTML.

Si necesitas:

cambiar orden estructural

puede ser necesario:

• Navigator;

• Grid;

• HTML seleccionado.

Utiliza la herramienta más pequeña posible.

Paso 135. Code component no sirve para “activar” una Landing

No pegues:

CSS
JavaScript

dentro de:

Code

esperando que modifique la página.

Code es un componente de contenido.

Para CSS:

utiliza la herramienta CSS correspondiente.

Paso 136. Prueba sin animaciones

Pregunta:

¿La Landing sigue siendo convincente y clara sin ningún efecto?

Debe ser:

SÍ

Si solo funciona cuando:

• cosas vuelan;

• Buttons palpitan;

• números animan;

el contenido necesita revisión.

Paso 137. Prueba sin imágenes

Lee:

H1
Beneficios
Proceso
Oferta
Prueba
FAQ
CTA

¿Se comprende la propuesta?

Si no:

las Images están reemplazando al mensaje.

Paso 138. Prueba solo Headings

Haz una lista:

H1
H2
H2
H2
H2
H2

Por ejemplo:

H1:
Gestiona tu presencia digital desde un único entorno

H2:
Por qué puede simplificar tu trabajo

H2:
Cómo funciona

H2:
Qué incluye

H2:
Casos reales

H2:
Preguntas frecuentes

H2:
Solicita información

¿El recorrido se entiende?

Si sí:

la estructura editorial es fuerte.

Paso 139. Prueba solo CTAs

Lista:

Solicitar información
Ver cómo funciona
Solicitar información
Ver proyecto
Solicitar información
Enviar consulta

Analiza:

• cuál es principal;

• cuáles son secundarios.

No conviertas todos en:

acciones principales

Paso 140. Revisa distracciones

Una Landing puede contener:

• Blog;

• Social;

• noticias;

• múltiples Links.

Pregunta:

¿esto ayuda a tomar la decisión?

Si no:

puede distraer.

No significa que debas eliminar toda navegación automáticamente.

Evalúa la intención.

Paso 141. Revisa contenido repetido

Es común repetir:

fácil
rápido
simple
completo

en:

• Hero;

• Benefits;

• Process;

• CTA.

Busca información concreta.

Paso 142. Evita marketing vacío

Ejemplo:

La solución que revolucionará tu futuro.

Mejor:

describe:

qué hace
+
para quién
+
qué utilidad aporta

Paso 143. Revisa afirmaciones absolutas

Busca:

siempre
garantizado
instantáneo
sin límites
el mejor
número 1

Comprueba si son correctas.

Si no:

modifica.

Paso 144. Revisa contenido temporal

Busca:

HOY
NUEVO
OFERTA
HASTA
2026

Estos contenidos necesitan mantenimiento.

Paso 145. Revisa todos los precios

Especialmente si aparecen en:

• Hero;

• Pricing;

• FAQ;

• CTA.

Si el mismo precio aparece tres veces:

tres lugares deben mantenerse actualizados.

Evita duplicar información variable sin necesidad.

Paso 146. Revisa condiciones

Si FAQ dice:

Incluye X

y Pricing:

X solo en Premium

existe una inconsistencia.

Revisa la Landing completa.

Paso 147. Revisa formularios

Comprueba:

• Labels;

• Names;

• IDs;

• required real;

• Button;

• recepción.

No consideres terminada la página antes de esta prueba.

Paso 148. Revisa todos los Links

Hero.

CTA intermedio.

Pricing.

Projects.

FAQ si contiene Links.

CTA final.

Haz clic realmente.

Paso 149. Revisa desktop completo

No únicamente Hero.

Haz scroll hasta:

la última Section

Busca:

• monotonía;

• excesos;

• huecos.

Paso 150. Revisa monitor grande

Comprueba:

• Width;

• Max Width;

• líneas de texto.

Un Paragraph no debería convertirse en:

una línea larguísima

de extremo a extremo.

Boxed y Max Width pueden ayudar.

Paso 151. Revisa tablet completa

Busca:

• Cards demasiado estrechas;

• Pricing;

• Form;

• texto + imagen.

No reduzcas Typography antes de ajustar el Grid.

Paso 152. Revisa mobile completo

Lee la Landing como si nunca hubieras visto desktop.

Pregunta:

¿cada Section prepara la siguiente?

Y:

¿puedo realizar la acción principal fácilmente?

Paso 153. Revisa longitud mobile

Una Landing de 12 Sections puede ser extensa.

Antes de ocultar:

clasifica:

ESENCIAL
ÚTIL
REDUNDANTE

Elimina primero redundancia.

Paso 154. Revisa CTA en distintos puntos

No necesitas que el visitante llegue al final.

Si ya está convencido después de Beneficios:

debería poder avanzar.

Por eso:

un CTA intermedio puede ser útil.

Paso 155. Pero no llenes cada Section de Buttons

Mantén:

puntos de acción estratégicos

Paso 156. Revisa formulario desde mobile real

Comprueba:

• teclado;

• Labels;

• Button;

• errores.

No te limites al preview.

Paso 157. Revisa mapa si existe

Una Landing normalmente no necesita Map

salvo que:

la ubicación sea relevante para la conversión

Por ejemplo:

• evento;

• local;

• showroom.

No agregues un mapa a una oferta digital solo para llenar espacio.

Paso 158. Revisa Footer

Footer pertenece a la plantilla.

Comprueba el recorrido final:

CTA / Form
↓
Footer

No debería existir:

500px de espacio vacío

entre ambos.

Si existe:

revisa la última Section.

Paso 159. Guardar por hitos

Hito 1:

arquitectura
↓
Guardar Cambios

Hito 2:

contenido real
↓
Guardar Cambios

Hito 3:

responsive
↓
Guardar Cambios

Hito 4:

estilo
↓
Guardar Cambios

No asumimos autosave.

Paso 160. Ver página

Después:

Ver página

No existe un segundo paso de publicación.

La prueba final debe realizarse en la página real.

Paso 161. Prueba como un visitante nuevo

Pregúntate:

¿qué es?

Después:

¿es para mí?

Después:

¿por qué me interesa?

Después:

¿puedo confiar?

Después:

¿qué hago?

Si alguna respuesta no está clara:

la Landing puede necesitar ajustes.

Paso 162. Prueba de los primeros segundos

Observa solo el Hero.

¿Puedes identificar:

PRODUCTO / SERVICIO
PÚBLICO
PROPUESTA
CTA

No necesariamente todos de forma literal,

pero la idea principal debe comprenderse.

Paso 163. Prueba del CTA

Muestra el texto aislado.

Por ejemplo:

Solicitar información

¿Sé qué acción representa?

Mucho mejor que:

Comenzar

si “comenzar” no tiene contexto suficiente.

Paso 164. Prueba de confianza

Pregunta:

¿Estoy demostrando confianza con información real o solo diciéndole al visitante que confíe?

Débil:

Somos los mejores.

Más concreto:

Proyecto real
Testimonio real
Proceso claro
Información de contacto

Paso 165. Prueba de objeciones

Lista las tres dudas principales.

Comprueba que la Landing las responda.

Si no:

puedes modificar:

• contenido;

• FAQ.

No necesitas agregar más efectos.

Paso 166. Prueba del flujo real

Para una Landing con formulario:

CTA
↓
Form
↓
Enviar
↓
Confirmación
↓
Recepción

Para WhatsApp:

CTA
↓
WhatsApp
↓
número correcto
↓
mensaje correcto

Para compra:

CTA
↓
producto/plan correcto
↓
importe correcto
↓
proceso real

Paso 167. No confundas conversión con visualización

Una Landing puede tener:

1.000 visitas

y ninguna consulta.

Pero el Editor de bloques por sí solo no demuestra:

• conversiones;

• rendimiento.

Si utilizas herramientas de medición externas:

su configuración es un proceso separado.

No inventes métricas dentro de la Landing para compensarlo.

Paso 168. No añadas tracking improvisado

Evita pegar scripts aleatorios generados por IA.

Si tu organización utiliza:

• analítica;

• píxeles;

• medición;

deben configurarse mediante un procedimiento apropiado para esas herramientas.

Este tutorial se centra en la construcción de la Landing.

Paso 169. Landing de una campaña temporal

Si la Landing corresponde a:

• evento;

• promoción;

• lanzamiento;

crea una lista de contenido que debe actualizarse.

Por ejemplo:

fecha
precio
disponibilidad
CTA
evento

Cuando termine:

actualiza o retira.

Paso 170. Landing permanente

Puede enfocarse en:

• producto;

• servicio;

• consulta.

Evita información temporal innecesaria.

Paso 171. IA para definir la arquitectura

Puedes utilizar ChatGPT, Claude o Gemini.

Prompt

Necesito crear una Landing Page en Waclis.

Objetivo principal:
[...]

Público:
[...]

Producto o servicio:
[...]

Funcionalidades reales:
[...]

Beneficios que puedo sostener:
[...]

Proyectos reales:
[...]

Testimonios reales:
[...]

Precio:
[si corresponde]

Acción real del CTA:
[...]

Propón:
1. orden de Sections;
2. objetivo de cada Section;
3. componentes Waclis apropiados.

No inventes:
- funcionalidades;
- clientes;
- estadísticas;
- testimonios;
- promociones;
- resultados.

IA para revisar Hero

Mi Landing tiene este Hero:

Eyebrow:
[...]

H1:
[...]

Paragraph:
[...]

CTA:
[...]

Público:
[...]

Objetivo:
[...]

Analiza si en los primeros segundos se entiende:
- qué ofrezco;
- para quién;
- utilidad;
- acción.

No reescribas todavía.

IA para redactar Hero

Información real:

Producto:
[...]

Público:
[...]

Problema que resuelve:
[...]

Funcionalidades:
[...]

Acción:
[...]

Redacta:
- Eyebrow opcional;
- H1 máximo 12 palabras;
- Paragraph máximo 35 palabras;
- CTA máximo 4 palabras.

No inventes beneficios ni garantías.
Español neutro.

IA para detectar beneficios inventados

Funcionalidades reales:

[listar]

Beneficios actuales:

[listar]

Indica cuáles pueden derivarse directamente de las funcionalidades y cuáles necesitan evidencia adicional.

No inventes evidencia.

IA para detectar marketing vacío

Revisa estos textos de Landing:

[pegar]

Marca expresiones vagas como:
- revoluciona;
- potencia;
- transforma;
- lleva al siguiente nivel;

cuando no estén acompañadas de una explicación concreta.

No reescribas todavía.

IA para ordenar Sections

Tengo estas Sections:

[listar]

Objetivo principal:
[...]

Público:
[...]

Ordena el recorrido desde:
- comprensión;
- interés;
- confianza;
- acción.

No agregues nuevas Sections salvo que falte una información esencial.

IA para revisar repetición

Hero:
[...]

Benefits:
[...]

Features:
[...]

CTA:
[...]

Detecta mensajes repetidos entre Sections.

Indica:
- frase;
- concepto;
- dónde se repite.

No reescribas todavía.

IA para diferenciar Benefits y Features

Estas son mis Cards:

[listar]

Clasifica cada una como:
- característica;
- beneficio;
- mezcla de ambos.

Explica si la estructura resulta coherente.

No inventes contenido.

IA para “Cómo funciona”

Este es el proceso real:

[pasos]

Necesito presentarlo en una Landing.

Resume en máximo 4 pasos.

No elimines:
- condiciones importantes;
- aprobaciones;
- tiempos;
si forman parte real del proceso.

IA para FAQ

Tengo estas dudas reales de clientes:

[listar]

Agrúpalas y redacta una FAQ clara.

No agregues preguntas ficticias.
No inventes condiciones comerciales.
No ocultes limitaciones.

IA para CTA

Objetivo principal:
[...]

Acción real después del clic:
[...]

CTA actual:
[...]

Comprueba si el texto coincide con el flujo.

No lo reescribas todavía.

IA para detectar urgencia artificial

Revisa esta Landing:

[texto]

Marca cualquier:
- escasez;
- cuenta regresiva;
- urgencia;
- promoción;
- “solo hoy”;
- “últimos cupos”;

que no tenga evidencia suministrada.

No reescribas.

IA para Pricing

Planes reales:

[datos]

Revisa:
- nombres;
- precios;
- características;
- CTA;
- etiqueta recomendada.

No inventes:
- descuentos;
- popularidad;
- precios anteriores;
- funcionalidades.

IA para testimonios

Estos son testimonios reales:

[pegar]

Necesito acortarlos para Cards.

Conserva:
- significado;
- tono;
- atribución.

No agregues elogios que el cliente no haya expresado.

IA para proyectos

Estos son proyectos reales:

[datos]

Selecciona cuáles ayudan mejor a respaldar esta Landing específica.

Objetivo de la Landing:
[...]

No inventes métricas.
No modifiques el alcance realizado.

IA para formulario

Objetivo de conversión:
[...]

Datos que necesitamos realmente:
[...]

Campos actuales:
[...]

Analiza si el Form solicita información innecesaria.

Clasifica:
- imprescindible;
- opcional;
- posiblemente innecesario.

No cambies la funcionalidad.

IA para revisar Form HTML

Este Form ya funciona en Waclis:

[HTML]

Identifica:
- Form;
- Names;
- IDs;
- Types;
- Button;
- atributos relevantes.

No modifiques nada.
No inventes cómo se procesa.

IA para responsive

Mi Landing utiliza:

Hero: 7+5
Benefits: 3 columnas
Process: 3 columnas
Feature: 6+6
Portfolio: 3 columnas
Pricing: 3 columnas
CTA: 8+4
Form: 7+5

Waclis utiliza Bootstrap 4.

Propón cómo adaptarlo:
- desktop;
- tablet;
- mobile.

No generes CSS cuando pueda resolverse desde Grid Row.

IA para auditar orden mobile

Esta es la jerarquía de mi Landing:

[pegar estructura]

Analiza cómo se leerá cuando todo se apile.

Busca:
- visual antes del contexto;
- dos Images consecutivas;
- CTA sin explicación;
- orden confuso.

No generes código.

IA para CSS localizado

Estoy trabajando en una Landing de Waclis.

Class raíz:
.landing-page

Necesito ajustar:
- títulos;
- descripciones;
- CTA;
- Cards.

No modificar:
- Header;
- Footer;
- otras páginas;
- Bootstrap.

Waclis utiliza Bootstrap 4.

No agregues JavaScript.
Devuelve solamente CSS localizado.

IA para detectar CSS global

Revisa este CSS:

[pegar]

Busca selectores globales sobre:

body
section
.container
.row
.col
h1
h2
h3
p
a
button
.card
img
input

Explica qué otras partes de Waclis podrían verse afectadas.

No modifiques nada.

IA para auditar Links

Estos son todos mis CTA:

Texto:
Destino:

[listar]

Comprueba:
- destinos repetidos;
- CTA con significado distinto pero mismo destino;
- CTA iguales con destinos diferentes;
- Links #;
- destinos que no coinciden con el texto.

No inventes URLs.

IA para auditoría final

Quiero auditar una Landing Page creada en Waclis.

Objetivo:
[...]

Público:
[...]

Estructura:
[...]

Contenido:
[...]

CTA:
[...]

Form:
[...]

Analiza:
1. claridad del Hero;
2. continuidad;
3. beneficios;
4. prueba de confianza;
5. objeciones;
6. CTA;
7. repeticiones;
8. afirmaciones sin evidencia;
9. responsive;
10. riesgos funcionales.

No inventes información.
No reescribas toda la Landing.

Buenas prácticas

Recomendamos:

• definir una conversión principal;

• conocer el público;

• explicar la propuesta desde el Hero;

• utilizar un H1 claro;

• mantener CTA coherentes;

• utilizar beneficios reales;

• explicar el proceso;

• mostrar características reales;

• aportar confianza mediante evidencia real;

• utilizar proyectos reales;

• utilizar testimonios reales;

• mostrar precios correctos;

• responder objeciones reales;

• evitar urgencia artificial;

• mantener formularios breves;

• probar el envío;

• revisar responsive;

• mantener CSS localizado;

• revisar toda la Landing como recorrido.

Errores frecuentes

Crear la Landing sin objetivo

Define una conversión.

Intentar que haga diez cosas a la vez

Prioriza una acción.

Hero abstracto

Explica la propuesta.

Utilizar varios H1 por tamaño

Mantén jerarquía.

CTA que no coincide con el destino

Alinea texto y flujo.

Utilizar “Comprar” cuando abre Contacto

No confundas acciones.

Utilizar “Reservar” cuando abre WhatsApp

Aclara lo que realmente ocurre.

Utilizar “Comenzar gratis” cuando existe pago

No engañes.

Repetir cinco CTA diferentes con el mismo destino

Mantén consistencia.

Colocar un CTA después de cada bloque

Utiliza puntos estratégicos.

Inventar beneficios

Parte de funcionalidades reales.

Inventar estadísticas

Solo datos verificables.

Inventar clientes

No utilices logos ficticios.

Inventar testimonios

Utiliza comentarios reales.

Inventar proyectos

Muestra trabajo real.

Inventar descuentos

Utiliza promociones reales.

Inventar urgencia

No simules escasez.

Utilizar Counter como falso Countdown

No son lo mismo.

Ocultar condiciones importantes en FAQ

Comunica con claridad.

Presentar una característica de plan como disponible para todos

Aclara alcance.

Diseñar una tabla de precios con datos desactualizados

Mantén información variable.

Agregar un Form y asumir que funciona

Realiza un envío.

Cambiar Names del Form por estética

Puede romper procesamiento.

Reemplazar submit por Link

No tienen la misma función.

Pedir demasiados datos

Reduce fricción.

Pedir secretos

Nunca en un formulario común.

Demasiadas imágenes decorativas

Cada recurso debe aportar.

Demasiados videos

Revisa rendimiento.

Demasiados Embeds

Reduce dependencias externas.

Depender de Hover

Touch debe funcionar.

Animar todo

La Landing debe funcionar sin animaciones.

Delays largos

No escondas información.

Mantener tres columnas en tablet aunque no sean legibles

Pasa a dos.

Mantener dos columnas en mobile solo para reducir largo

Prioriza lectura.

Ocultar Sections importantes en mobile

Adapta.

Duplicar Landing desktop y mobile

Mantén una estructura responsive cuando sea posible.

Utilizar Height fija

Permite crecimiento.

Utilizar Position absolute para layout básico

Utiliza Grid.

Utilizar grandes márgenes

Corrige estructura.

Aplicar .row globalmente

Puede romper toda la página.

Aplicar .card globalmente

Puede modificar distintos tipos de Card.

Aplicar a o button globalmente

Puede afectar otras áreas.

Agregar Bootstrap adicional

Waclis utiliza Bootstrap 4.

Pedirle a IA que reescriba todo

Realiza modificaciones pequeñas y controladas.

No probar la conversión final

El diseño por sí solo no confirma el flujo.

Flujo profesional recomendado

1. DEFINIR CONVERSIÓN
↓
2. DEFINIR ACCIÓN REAL
↓
3. DEFINIR PÚBLICO
↓
4. DEFINIR PROPUESTA
↓
5. IDENTIFICAR OBJECIONES
↓
6. REUNIR INFORMACIÓN REAL
↓
7. DEFINIR ARQUITECTURA
↓
8. DEFINIR H1 / H2 / H3
↓
9. CREAR HERO
↓
10. CREAR CTA PRINCIPAL
↓
11. AGREGAR CONFIANZA SI EXISTE
↓
12. EXPLICAR NECESIDAD
↓
13. CREAR BENEFICIOS
↓
14. CREAR PROCESO
↓
15. MOSTRAR QUÉ INCLUYE
↓
16. AGREGAR VISUALES
↓
17. AGREGAR PROYECTOS REALES
↓
18. AGREGAR TESTIMONIOS REALES
↓
19. AGREGAR PRICING SI CORRESPONDE
↓
20. CREAR FAQ REAL
↓
21. CREAR CTA FINAL
↓
22. CREAR FORM SI CORRESPONDE
↓
23. CONFIGURAR LINKS
↓
24. CONFIGURAR IDS
↓
25. CREAR CLASSES
↓
26. REVISAR LINKED STYLES
↓
27. REVISAR DESKTOP
↓
28. REVISAR TABLET
↓
29. REVISAR MOBILE
↓
30. REVISAR NAVIGATOR
↓
31. REVISAR CSS
↓
32. REVISAR CONTENIDO
↓
33. GUARDAR CAMBIOS
↓
34. VER PÁGINA
↓
35. PROBAR CTA
↓
36. PROBAR FORM
↓
37. VALIDAR CONVERSIÓN COMPLETA

Checklist estratégico

• Existe un objetivo principal.

• Sé quién es el público.

• La propuesta es clara.

• Sé qué ocurre después del CTA.

• Identifiqué objeciones.

• La arquitectura responde esas objeciones.

• No hay demasiados objetivos secundarios.

• Cada Section tiene una función.

• La Landing conduce hacia una acción concreta.

Checklist del Hero

• La propuesta se entiende.

• El H1 es claro.

• Existe un único H1 principal.

• El Paragraph aporta contexto.

• CTA principal es reconocible.

• CTA secundario no compite.

• El visual aporta.

• Mobile mantiene el contenido primero cuando corresponde.

• No depende de una imagen para explicar la propuesta.

Checklist de confianza

• Los clientes son reales.

• Los logos pueden mostrarse.

• Los proyectos son reales.

• Los testimonios son reales.

• Las métricas son verificables.

• No utilicé marcas como decoración.

• No inventé resultados.

• No exageré el alcance de los trabajos realizados.

Checklist de beneficios y características

• Los beneficios pueden sostenerse.

• Las características existen.

• Beneficio y característica no se confunden.

• No utilicé marketing vacío.

• No inventé resultados comerciales.

• Los títulos son claros.

• Los Paragraphs explican utilidad.

• El Grid se adapta a tablet y mobile.

Checklist del proceso

• Los pasos corresponden al proceso real.

• No eliminé pasos importantes.

• No prometí “1 clic” si no es así.

• El orden se comprende.

• Mobile mantiene la secuencia.

• No agregué animaciones necesarias para entenderlo.

Checklist de Pricing

• Los precios son correctos.

• Las condiciones son correctas.

• Los planes incluyen lo que se indica.

• No inventé precios anteriores.

• No inventé descuentos.

• No marqué “Más elegido” sin datos.

• CTA coincide con el flujo.

• Las URLs corresponden al plan correcto.

• La información variable podrá mantenerse.

Checklist de FAQ

• Las preguntas corresponden a dudas reales.

• Las respuestas son correctas.

• No oculté condiciones esenciales.

• No agregué preguntas solo para generar contenido.

• Los Accordions funcionan.

• Los IDs no están duplicados.

• Mobile es utilizable.

Checklist del CTA

• El CTA principal es consistente.

• El texto explica la acción.

• No utiliza “Haz clic aquí”.

• No promete una acción diferente.

• No utiliza urgencia falsa.

• No utiliza escasez falsa.

• Los Links tienen destinos reales.

• No existen #.

• Mobile es fácil de utilizar.

• Probé cada CTA.

Checklist del formulario

• Solo solicita datos necesarios.

• Los Labels son claros.

• Types fueron revisados.

• Names fueron revisados.

• IDs son únicos.

• Campos obligatorios funcionan realmente.

• El Button sigue siendo funcional.

• No modifiqué atributos funcionales sin comprenderlos.

• No existen secretos.

• Probé el envío.

• Comprobé recepción.

• Comprobé todos los campos enviados.

Checklist responsive

• Revisé Hero.

• Revisé Benefits.

• Revisé Process.

• Revisé texto + Image.

• Revisé Portfolio.

• Revisé Pricing.

• Revisé FAQ.

• Revisé CTA.

• Revisé Form.

• Tablet tiene una configuración propia cuando corresponde.

• Mobile mantiene orden lógico.

• No existe scroll horizontal.

• No oculté contenido esencial.

Checklist técnico

• Utilicé Navigator.

• No quedan Sections vacías.

• Revisé Linked styles.

• Los IDs son únicos.

• Utilicé Classes para estilos compartidos.

• No modifiqué .container globalmente.

• No modifiqué .row globalmente.

• No modifiqué .card globalmente.

• No modifiqué a globalmente.

• No modifiqué button globalmente.

• No agregué Bootstrap adicional.

• Waclis sigue utilizando Bootstrap 4.

• No agregué JavaScript innecesario.

• El CSS personalizado tiene scope.

Checklist de credibilidad

• No inventé clientes.

• No inventé testimonios.

• No inventé cifras.

• No inventé ventas.

• No inventé conversiones.

• No inventé descuentos.

• No inventé urgencia.

• No inventé disponibilidad.

• No inventé funcionalidades.

• No prometí resultados garantizados sin fundamento.

• No hice pasar una acción de consulta por una compra o reserva.

Checklist de mantenimiento

• Identifiqué precios que pueden cambiar.

• Identifiqué promociones.

• Identifiqué fechas.

• Identifiqué Badges “Nuevo”.

• Identifiqué Links externos.

• Revisaré proyectos.

• Revisaré testimonios.

• Revisaré FAQ.

• Revisaré CTA.

• Revisaré formulario.

Checklist final

• Guardé los cambios.

• Utilicé Ver página.

• Revisé toda la Landing en desktop.

• Revisé toda la Landing en tablet.

• Revisé toda la Landing en celular.

• Probé los CTA.

• Probé los Links internos.

• Probé los Links externos.

• Probé el formulario.

• Probé WhatsApp si existe.

• Probé compra/reserva si corresponde.

• El Hero se comprende rápidamente.

• La Landing explica por qué la propuesta es relevante.

• Existe evidencia real.

• Se resuelven objeciones.

• El visitante sabe qué hacer.

• La acción final realmente funciona.

En resumen

Una Landing Page profesional no comienza con:

¿QUÉ DISEÑO PUEDO HACER?

Comienza con:

¿QUÉ ACCIÓN QUIERO QUE REALICE EL VISITANTE?

Después:

¿PARA QUIÉN ES?

Luego:

¿QUÉ NECESITA SABER ANTES DE ACTUAR?

La Landing puede organizarse:

PROPUESTA
↓
CONFIANZA
↓
NECESIDAD
↓
BENEFICIOS
↓
PROCESO
↓
CARACTERÍSTICAS
↓
EVIDENCIA
↓
OBJECIONES
↓
CTA
↓
CONVERSIÓN

El Hero debería explicar:

QUÉ
+
PARA QUIÉN
+
UTILIDAD
+
ACCIÓN

Los beneficios:

FUNCIÓN REAL
↓
UTILIDAD REAL

La confianza:

PROYECTOS REALES
+
CLIENTES REALES
+
TESTIMONIOS REALES
+
DATOS REALES

No:

LOGOS INVENTADOS
+
MÉTRICAS INVENTADAS
+
TESTIMONIOS GENERADOS

Respecto de los CTA:

MISMA CONVERSIÓN
→ PUEDE REPETIRSE

Pero:

CADA SECTION
→ NUEVA ACCIÓN

genera distracción.

Respecto de la urgencia:

URGENCIA REAL
→ puede comunicarse

Mientras:

URGENCIA FALSA
→ no

Respecto del Form:

FORMULARIO BONITO
≠
FORMULARIO FUNCIONAL

Debes:

COMPLETAR
↓
ENVIAR
↓
COMPROBAR CONFIRMACIÓN
↓
COMPROBAR RECEPCIÓN

Respecto del responsive:

DESKTOP
→ composición

TABLET
→ adaptación real

MOBILE
→ recorrido vertical lógico

No:

DESKTOP
→ reducir hasta que entre

Respecto del código:

GRID ROW
+
BOOTSTRAP 4
+
CLASSES
+
CSS LOCALIZADO

antes que:

POSITION ABSOLUTE
+
MÁRGENES GIGANTES
+
LIBRERÍAS NUEVAS
+
JAVASCRIPT INNECESARIO

Y finalmente

el flujo profesional es:

OBJETIVO
↓
PÚBLICO
↓
PROPUESTA
↓
OBJECIONES
↓
ARQUITECTURA
↓
CONTENIDO REAL
↓
DISEÑO
↓
RESPONSIVE
↓
CTA
↓
FUNCIONALIDAD
↓
GUARDAR CAMBIOS
↓
VER PÁGINA
↓
REALIZAR LA CONVERSIÓN
↓
COMPROBAR EL RESULTADO

Una Landing Page está correctamente construida cuando una persona puede responder:

“Entiendo qué me ofrecen, entiendo por qué puede ser relevante para mí, encuentro razones reales para confiar, mis principales dudas están respondidas y sé exactamente qué ocurrirá si decido avanzar.”

Cuando además esa acción final funciona de verdad, la Landing deja de ser simplemente una página comercial atractiva y pasa a convertirse en un recorrido completo y coherente.