Landings
de conversión.

El brief

Antes de diseñar o pedirle una maqueta a la IA, el solicitante entrega un brief mínimo. Sin estos datos no se parte:

1. Objetivo de conversión: qué tiene que hacer la persona.
2. Destino del botón principal: la dirección exacta de la plataforma, formulario, correo o WhatsApp.
3. Público: a quién le habla.
4. Mensaje principal: la idea que tiene que quedar aunque se lea solo el hero.
5. Datos duros: fecha, horario, lugar, precio, qué incluye y medios de pago.
6. Momento: antes, durante o después del evento, y si se repite.
7. Materiales: logos, fotos, videos, programa y brochure, o quién los entrega y cuándo.
8. Dónde se publica: en un servidor propio o en Elementor, y en qué sitio.
9. Fecha de publicación y quién aprueba.
10. Mediciones: qué herramientas se usan, qué se mide y quién lo revisa.

Lo que falte no detiene el trabajo: queda visible en la maqueta como “por confirmar” y en una lista de consultas para el solicitante. Nunca se inventa un dato.

Prompt para partir. Cópialo y completa el brief:

Vamos a armar una landing de conversión siguiendo la página
"Landings de conversión" de Solar (https://utiliza.me/solar/patrones/landings/)
y las definiciones de Solar (https://utiliza.me/solar/llms.txt).
Para las animaciones y la interacción usa el Solar Landing Kit y su
plantilla (https://utiliza.me/solar/patrones/landings/kit/).

Brief:
- Objetivo de conversión:
- Destino del botón principal (URL, formulario, correo o WhatsApp):
- Público:
- Mensaje principal:
- Datos duros (fecha, horario, lugar, precio, qué incluye, medios de pago):
- Momento (antes, durante o después del evento) y si se repite:
- Materiales adjuntos (logo, brochure, fotos, video, programa):
- Dónde se publica (servidor propio o Elementor), sitio y si ya tiene página de prueba:
- Mediciones (herramientas, qué se mide y quién lo revisa):

No hagas nada todavía. Primero propón el plan de tareas de la página de
Solar, ajustado a este caso, con lo que entregarás en cada una. Espera mi
aprobación antes de cada tarea. Marca como "de ejemplo" o "por confirmar"
todo lo que falte, sin inventar datos. Español de Chile, con tuteo.

Durante el trabajo, los cambios se piden de a uno y con contexto: “el titular se corta en el teléfono”, no “arréglalo”.

Una landing de conversión

Es una página que presenta una sola cosa (un evento, un producto, una actividad) y lleva a la persona a donde ocurre la acción: comprar una entrada, inscribirse, escribir. Reemplaza a los PDF y piezas que se envían por correo, con la misma información, pero se puede actualizar, medir y compartir con un enlace.

Formas de armar una landing

Con el diseño listo, la landing se arma en WordPress con el editor de Elementor, o en HTML. El HTML lo arma un diseñador o desarrollador front-end, o la IA, que puede hacer tanto el diseño como el desarrollo. Después se pega en una página en blanco de Elementor o se sube a un servidor.

Cambia qué puede llevar la página, quién la mantiene después y cuánto demora en salir.

Lo que sigue responde al caso de la CCS, que publica sus portales públicos en WordPress. Un HTML en un servidor propio puede llevar de todo, pero pasa por el análisis del área de seguridad, que toma tiempo, y cada cambio pasa por varias personas. En WordPress, el contenido se publica rápido y con definiciones de seguridad ya aprobadas. Si tu empresa trabaja de otra forma, toma estas reglas como punto de partida.

Esta página trata de la landing en HTML y de su versión para Elementor. Las reglas son las mismas si la arma una persona o la IA; el recorrido y el prompt están pensados para hacerlo con IA.

• La acción ocurre en otro sistema: una plataforma de venta de entradas, un formulario, un correo o WhatsApp. La landing solo tiene botones que llevan ahí.
• No lleva formularios, login, buscadores, noticias ni contenido que cambie solo, porque en Elementor se pega como código fijo que no se conecta con WordPress. En un servidor propio podría llevarlos, con su propio desarrollo y el análisis de seguridad que eso implica.
• Si se necesita algo de eso, se arma con el editor de Elementor o se enlaza a la página que ya lo tiene, por ejemplo “Ver noticias”.

Primero: ¿landing o página del sitio?

Se recomienda cuando:

• Hay un evento o campaña con fecha y una sola acción: comprar, inscribirse, escribir.
• La gente llega dirigida desde correos, redes, avisos o códigos QR.
• Reemplaza a un PDF o a una pieza que se enviaría por correo.
• Tiene fecha de término: cuando pasa el evento, esa dirección recibe la landing siguiente.

No conviene cuando:

• El contenido es permanente. Va como página del sitio.
• Hay varias acciones del mismo peso. Cada una necesita su propia landing, o es una página del sitio.
• Ya hay una página del sitio que hace lo mismo. Se mejora esa, no se duplica.

Después: ¿en HTML o con el editor de Elementor?

• En HTML cuando el diseño es propio del evento y los textos quedan fijos hasta que termine.
• Con el editor de Elementor cuando lleva formulario, noticias o contenido que se actualiza solo, cuando va a estar publicada mucho tiempo, o cuando la va a editar seguido alguien que no toca código.

El detalle de cada forma está en Formas de armar una landing.

Antes de hacer cualquier cosa, la IA propone un plan de tareas con lo que va a entregar en cada una. Ninguna tarea parte sin la aprobación de la anterior.

Estructura base de una landing de evento

Es una propuesta de partida, no una regla: se adapta a cada evento. Las secciones siguen el orden de las preguntas que se hace la persona antes de comprar o inscribirse.

1. Header: logo, menú a las secciones y botón principal siempre visible.
2. Hero: qué es, cuándo y dónde, botón principal y una acción secundaria. Opcional: cuenta regresiva y un visual.
3. Por qué ir: una frase con la propuesta y los datos principales.
4. Qué pasa: programa o contenido, ordenado como lo vive la persona.
5. Quiénes: speakers o protagonistas, con foto, cargo y empresa.
6. Prueba social: videos o números de ediciones anteriores, testimonios.
7. Cuánto y cómo: precio, qué incluye, descuentos y botón principal.
8. Cómo llegar y preguntas frecuentes: dirección, mapa, estacionamiento, transporte y dudas de compra.
9. Auspiciadores: logos por categoría y un bloque para quien quiera auspiciar.
10. Pie: cierre con el mensaje y el botón principal, organizadores, documentos, contacto y redes.

El botón principal aparece al menos en el header, el hero, la sección de precio y el pie. Las páginas que la landing no reemplaza (noticias, contacto) van como enlace en el menú y en el pie.

Antes, durante y después del evento

• Antes y durante: es la misma landing. El día del evento solo cambia el contenido y el botón principal pasa de “comprar” a “ver la transmisión” o “cómo llegar”.
• Después: se arma una landing nueva para esa etapa. La anterior no se deja vencida: nada de cuenta regresiva en cero, botones de compra a una venta cerrada ni textos en futuro sobre algo que ya pasó. Se publica en la misma dirección.

La landing de después se planifica antes del evento, para publicarla apenas termine.

Textos de los botones

• Verbo y lo que obtiene la persona, en tuteo: “Compra tu entrada”, “Descarga el brochure”, “Avísame cuando abran las entradas”. Nada de “Haz clic aquí”, “Enviar” ni “Más información”.
• Cortos: idealmente 2 a 4 palabras. El contexto va en el texto de al lado.
• Dicen a dónde llevan cuando sacan a la persona de la página: “Ver noticias”, “Abrir en Google Maps”, “Escríbenos”.
• El mismo texto para la misma acción en toda la página.
• Sin promesas que el destino no cumple: si la venta todavía no abre, el botón cambia, por ejemplo a “Avísame”.
• Los enlaces que abren otra pestaña o descargan un archivo lo indican: ícono de descarga en los PDF y “se abre en una pestaña nueva” para lectores de pantalla.

Más reglas de redacción en Voz y tono.

Titular y bajada del hero

El hero se lee en 5 segundos y tiene que bastar para decidir si seguir bajando.

• El titular es una idea, no una descripción: dice por qué importa el evento, no cómo se llama. El nombre ya está en el logo.
• La bajada dice qué es y para quién, en una o dos líneas.
• Los datos duros van aparte y a la vista: fecha con día de la semana, horario y lugar.
• Una sola palabra destacada como máximo en el titular.
• El titular se revisa en el teléfono: que no quede una palabra sola en la última línea y que no se corte. Si hace falta, se fuerzan los saltos de línea.

Si la landing cambia de momento, el titular cambia con ella. Por ejemplo, después del evento: “Gracias por venir. Nos vemos el próximo año”.

Para armarlo, parte de Hero › De landing, en Componentes.

Contenido de ejemplo en las maquetas

Cuando falta un contenido, la maqueta igual lo muestra para que se entienda la sección, pero siempre se nota que es de ejemplo:

• Etiqueta visible junto al contenido (“Cifra de ejemplo”, “Fotos de ejemplo”, “Formulario por definir”), con un mismo estilo en toda la página.
• Testimonios y citas: solo texto de relleno que se lea como tal, con “Nombre y apellido” y “Cargo, empresa”. Nunca una cita inventada a nombre de una persona o empresa real.
• Cifras: de ejemplo hasta que el organizador las confirme. Las que ya se pueden contar van reales.
• Fotos que faltan: espacios con forma y leyenda, no fotos de banco que parezcan del evento.
• Botones sin destino: apuntan a # y llevan su etiqueta “por definir”.

Antes de publicar se revisa que no quede ninguna etiqueta de ejemplo ni ningún #.

Una landing tiene que cautivar para que la persona haga clic en el botón principal. Por eso no sigue Solar al 100 %: separa lo que se mantiene de la marca de lo que se crea para cada evento.

Qué se mantiene y qué se crea

• Cada cambio tiene una razón: que el evento se reconozca y destaque, no variar por variar.
• Para lo libre, busca referentes: landings de eventos, campañas y conferencias, más allá del rubro.
• Es una propuesta inicial. Qué se mantiene se define con Marketing.
• Header y footer para landings: vienen próximamente en Solar. Ahí se definirá qué partes son obligatorias y cuáles opcionales.

Accesibilidad mínima

• Contraste según las reglas de Solar, también sobre imágenes, videos y degradados.
• Un solo título principal (h1) y títulos de sección en orden.
• Se usa solo con teclado: todo se alcanza con Tab y el foco se ve.
• Áreas táctiles de al menos 44 × 44 px en botones, íconos y menú.
• Texto alternativo en las imágenes que dicen algo y vacío en las decorativas.
• Botones de íconos con nombre para lectores de pantalla.
• Movimiento: con “reducir movimiento”, los videos y animaciones se detienen o pasan a imagen fija.
• Idioma declarado como español de Chile.

Video

• Si se reproduce solo, va sin sonido. En Elementor hay que activar “silenciado”, o el video queda en pausa.
• Siempre con imagen fija de respaldo: se ve mientras carga, si falla y con “reducir movimiento”.
• Liviano: pocos segundos, sin audio, MP4 H.264, idealmente bajo 2 MB.
• No compite con el texto: si va detrás del titular, el contraste se revisa sobre el cuadro más claro.
• Si se repite sin fin, lo ideal es un botón para pausarlo; si no, al menos se detiene con “reducir movimiento”.
• Videos largos (charlas, resúmenes): miniatura con botón de play que abre YouTube.

Maqueta local

La IA arma primero una página HTML que se abre directo en el navegador, sin WordPress ni Elementor. Sobre ella se revisa el diseño y se conversa con la IA para ajustarlo. Ya cumple las reglas de seguridad y de aislamiento de estilos, así que sirve para un servidor propio y, si se pide, pasa a Elementor sin cambios de diseño.

Estructura y archivos

• Todo el contenido va dentro de un solo contenedor, <div id="ccs-landing">, con todo el CSS bajo #ccs-landing y variables con prefijo --lp-. Así no choca con los estilos de un sitio y pasa a Elementor sin cambios de diseño.
• Una carpeta propia: el HTML y una carpeta assets/ con el CSS, el JavaScript, las tipografías, las imágenes, los videos y los PDF.
• Cumple las reglas de Seguridad desde la primera maqueta.

Interacción y JavaScript

• HTML nativo: preguntas frecuentes con <details>, enlaces a secciones de la misma página y videos con <video>.
• Menú móvil solo con CSS: el botón es un enlace que abre el panel con :target. Al elegir una sección se cierra, y tiene su botón para cerrar.
• Efectos con CSS al pasar el mouse o con el foco del teclado, bajo “reducir movimiento”.
• En la landing en HTML, el JavaScript va en archivos aparte y sale del Solar Landing Kit: una librería propia con los efectos y comportamientos ya revisados por el área de seguridad de la CCS. No se escribe JavaScript a mano para una landing; si falta un efecto, se agrega al kit en una versión nueva.
• Los efectos se activan con atributos data-ccs-* en el HTML: no hay que escribir código. El catálogo del kit muestra la demo, el código y los atributos de cada uno, y trae una plantilla de landing para partir.
• La versión va en el nombre del archivo (kit-1.1.js). Una landing publicada queda fijada a la versión con que se analizó, y las versiones conviven para no romper las landings ya publicadas.
• En producción, el kit se carga desde el servidor de tu empresa, no desde acá: el catálogo es la referencia.
• En la versión para Elementor no se usa JavaScript propio. Lo que lo necesita (por ejemplo, una cuenta regresiva) se hace con un elemento de Elementor o con el JavaScript que el tema ya carga en el sitio.
• Sin carruseles ni sliders: las listas largas van en grilla.

En la versión para Elementor, si un efecto necesita JavaScript y ni Elementor ni el tema lo tienen, no se usa.

La landing en HTML cumple las reglas de seguridad de la CCS para páginas HTML: son las que revisa el análisis de seguridad antes de publicar. La política de seguridad de contenido (CSP) y los demás headers los configura quien administra el servidor; la landing queda lista para que una CSP estricta no la rompa.

Excepción para Elementor. La versión para Elementor cumple el mismo nivel de seguridad que el resto de las páginas armadas con Elementor, y por eso algunas de estas reglas cambian. Están en Seguridad en Elementor.

Si una landing necesita algo fuera de estas reglas, se consulta con el área de seguridad de tu empresa antes de armarla.

Pasa por el análisis de seguridad y el paso a producción, así que es la forma que más demora. La carpeta de la landing, con el HTML y assets/, se sube tal cual.

• Permisos: archivos en 644 y carpetas en 755. Con 600, el servidor responde 403.
• Cuando cambian el CSS o el JavaScript, se cambia el número ?v= de sus enlaces, para que el navegador no use la versión anterior guardada.
• Metadatos con la dirección final: canonical, og:url y og:image.
• La CSP y los demás headers los configura quien administra el servidor, con el listado de orígenes externos de la landing.
• La versión que pasa el análisis de seguridad es la que se publica.
• La página publicada se revisa en incógnito.

Solo si se pide. Es una excepción a las reglas de Seguridad: la landing se publica como una página más de WordPress con Elementor y cumple el mismo nivel de seguridad que ellas.

Se parte de la landing en HTML ya aprobada y se adapta en cuatro cosas: el CSS pasa a un <style> dentro del bloque de estilos, las tipografías se cargan desde Google Fonts, los medios se suben a la biblioteca de medios y el JavaScript propio se quita o se reemplaza por un elemento de Elementor o del tema. El Solar Landing Kit solo se usa acá si sus archivos están alojados en ese mismo sitio y aprobados; si no, el efecto se reemplaza o se quita.

Seguridad en Elementor

Los sitios en WordPress con Elementor ya tienen el visto bueno del área de seguridad. Mientras la landing no se salga de lo que hace Elementor, no necesita un análisis de seguridad propio para publicarse. Para eso, el HTML que se arma con IA cumple estas dos listas.

Si una landing necesita algo que no está en “Se puede”, ya no cumple: se consulta con el área de seguridad de tu empresa antes de armarla. Lo demás de la sección Seguridad se mantiene, salvo tres cosas: el CSS va en un <style>, las tipografías se cargan desde Google Fonts y no se usa JavaScript propio.

Página de prueba en el sitio de destino

Cada sitio tiene su propio tema y sus plugins, y afectan la landing de forma distinta. Antes de la primera landing de un sitio, se revisa cómo es:

1. Crea una página nueva con Elementor.
2. En Ajustes de página › Estructura de página, elige Lienzo de Elementor: página en blanco, sin el header ni el footer del sitio.
3. Agrega un contenedor con diseño Flexbox, ancho de contenido Ancho completo, huecos 0 y, en Avanzado, relleno 0.
4. Dentro del contenedor, agrega un widget HTML con un texto de prueba: un título, un párrafo, una lista y un enlace.
5. Publica la página y pásale la dirección a la IA.

La IA revisa la página publicada en una ventana de incógnito:

• Qué estilos pone el tema a títulos, párrafos, listas, enlaces y al <body>.
• Qué relleno, separación y ancho máximo deja Elementor alrededor del contenedor, y si su CSS carga.
• Qué id y clases tienen estilos en el tema.
• Qué scripts carga el sitio en todas las páginas y qué necesitan para funcionar.
• Qué agregan los plugins aunque la página no los use: sellos de reCAPTCHA, optimizadores que retrasan scripts.
• Qué tipografías y mediciones ya están cargadas.

El resultado queda anotado y sirve para todas las landings de ese sitio.

Aislar la landing de los estilos del sitio

• Todo el contenido va dentro de un solo contenedor, <div id="ccs-landing">, y todo el CSS de la landing parte con #ccs-landing.
• Las variables de CSS llevan un prefijo propio: --lp-.
• Se anulan los estilos heredados del tema dentro de la landing antes de aplicar los propios.
• Se neutraliza lo que agregan Elementor y el tema, según la página de prueba: relleno, separación, ancho máximo, márgenes y overflow del <body>. Esas reglas usan :has(#ccs-landing).
• Se ocultan los elementos del sitio que no corresponden a la landing.
• Se usan id y clases propios que el tema no tenga estilizados.

Estas reglas van al comienzo del CSS de la landing y se reutilizan en todas las landings del mismo sitio.

Archivos para Elementor

Solo con la maqueta aprobada, la IA genera:

1. Dos archivos HTML para Elementor, que se pegan en dos widgets HTML dentro del contenedor de la página: uno de estilos (Google Fonts y el <style> con todo el CSS) y uno de contenido (el <div id="ccs-landing">).
2. Las instrucciones para quien la publique.

Al preparar y publicar:

• Cada bloque pesa menos de 100 KB. Si se acerca, se divide.
• Sin comentarios (<!-- --> ni /* */) en los bloques. Las notas van en un archivo aparte.
• Imágenes, videos y PDF se suben a la biblioteca de medios, y la IA reemplaza las direcciones de la maqueta por las que entrega WordPress. WordPress puede cambiar el nombre (agrega -1 o -scaled) y achica las imágenes de más de 2560 px.
• Título, descripción, imagen para compartir y favicon se configuran en la página y en el plugin de SEO, no en el bloque.
• La página publicada se revisa en incógnito, no en el editor de Elementor.

Si después de publicar hay que cambiar el diseño, se ajusta primero la maqueta local y se vuelven a generar los archivos.

Publicar los bloques en Elementor

La landing se publica en una página en blanco, con un widget HTML para cada bloque:

1. Crea una página nueva y ábrela con Elementor.
2. En Ajustes de página › Estructura de página, elige Lienzo de Elementor: página en blanco, sin el header ni el footer del sitio.
3. Agrega el mismo contenedor de la página de prueba: diseño Flexbox, ancho de contenido Ancho completo, huecos 0 y, en Avanzado, relleno 0.
4. Dentro del contenedor, agrega un widget HTML y pega el archivo de estilos.
5. Debajo, agrega un segundo widget HTML y pega el archivo de contenido.
6. Publica la página y revísala en una ventana de incógnito.

• Se implementan las mediciones que defina el área responsable de la campaña, como Google Analytics, el píxel de Meta u otras plataformas de anuncios. Se definen en el brief.
• Si el sitio ya tiene las mediciones (con un plugin o un administrador de etiquetas), se usan esas y no se agrega nada a la landing.
• En la versión para Elementor, si el sitio no tiene nada, se colocan en la página misma, con el código oficial de cada herramienta, en un widget HTML aparte de los bloques de la landing.
• En la landing en HTML, los códigos de medición son scripts de terceros: se consultan con el área de seguridad de tu empresa antes de agregarlos y su origen va en el listado de orígenes externos.
• Los botones son enlaces normales (<a href="…">), para que se registren los clics que salen a otro sitio y las descargas. Para distinguir un botón de otro, se le pone un id o una clase propia y la medición se configura en la herramienta.
• Los enlaces que se comparten hacia la landing llevan parámetros de campaña: ?utm_source=…&utm_medium=…&utm_campaign=….
• Las compras, inscripciones o mensajes reales se miden en el sistema de destino: entradas vendidas, formularios enviados, correos recibidos. La landing mide el clic.
• Antes de publicar se prueba que se registren las visitas y los clics del botón principal.