Landinker

Editor de Landings

¿Qué es el Editor de Landings?

El Editor de Landings de Landinker es la herramienta visual que permite crear, editar y personalizar páginas dentro de la plataforma.
Su objetivo es brindar una experiencia intuitiva y flexible, para que cualquier usuario pueda construir landing pages optimizadas para la conversión, sin necesidad de conocimientos técnicos avanzados.

¿Cómo funciona?

• Cada landing está compuesta por componentes (Navbar, Hero, Grid, etc.).
• Los componentes tienen propiedades (props) que definen su apariencia y comportamiento.
• El editor permite arrastrar, soltar, ordenar y configurar componentes de manera modular.
• Una landing puede tener diferentes estados (borrador, publicada, archivada).
• Cada landing tiene un path único que determina en qué URL estará disponible.

Nota: Esta documentación explica el uso del editor y su lógica de funcionamiento desde el punto de vista del usuario. No incluye detalles internos de la API de Puck.

Crear una landing

Al crear una landing podés elegir cómo arrancar:

• Desde un template: la página nace con secciones ya armadas (Hero, precios, testimonios, footer, etc.) que después editás libremente.
• Desde cero: una página en blanco para armar bloque por bloque.

Los templates están agrupados por para qué sirven, y "Desde cero" queda siempre arriba de todo. Los que se llenan con tu contenido te lo avisan en la tarjeta, para que sepas de entrada si necesitás tener algo cargado.

Nota de blog: antes de publicarla, elegí qué nota muestra. Si la dejás sin elegir, en la página publicada se ve "Nota no encontrada" — en el editor, en cambio, se muestra una nota de ejemplo. También podés vincularla a un parámetro dinámico de la ruta y tener una sola página que sirva para todas las notas.

Catálogo: el botón "Agregar al carrito" de cada tarjeta viene apagado, porque depende de que tengas la tienda habilitada (planes Pro y Enterprise). Lo prendés desde el panel del componente.

En ambos casos, después cargás los datos principales (nombre, paths, SEO) y pasás al editor visual.

Propiedades (Props)

Las propiedades son configuraciones específicas de cada componente.
Ejemplos:

• Colores (backgroundColor, textColor)
• Tamaños (height, width, borderRadius)
• Contenido (title, subtitle, items, src)
• Comportamiento (sticky, autoplay, required)

Estas propiedades permiten personalizar la landing a nivel diseño y funcionalidad.

Componentes

Los componentes son los bloques de construcción de las landings.

Categorías

• Esenciales: Navbar, Footer
• Secciones: Hero, Cta, Pricing, Testimonials, Stats, Steps, Team, LogoCloud, CountdownTimer
• Contenido: Card, FAQ, Accordion, Tabs
• Multimedia: Image, Video, Carousel, Gallery, Embed, Map
• Tipografía: HeadingBlock, Paragraph, List, IconText
• Acciones: Button, Form, Newsletter, Social
• Productos: ProductsGrid, ProductTitle, ProductPrice, ProductImage, ProductDescription, ProductCategory
• Blog: BlogIndex, BlogNote
• Estructura: Container, Flex, Grid, Space, Divider

Los componentes se pueden anidar en contenedores (Container, Flex, Grid). Para editar sus propiedades con controles visuales (color, espaciado, dimensiones, íconos y variables), ver Editar componentes.

Componentes de Producto

Los módulos de producto te permiten:

• Mostrar listas de productos con ProductsGrid.
• Vincular bloques individuales (ProductTitle, ProductPrice, ProductImage, ProductDescription, ProductCategory) a un producto específico.
• Usar productId fijo (ObjectId) o dinámico (variable desde el path).

Cuando el productId es dinámico, se recomienda configurar paths con segmentos como :idProducto y usar la variable resultante {{IDPRODUCTO}}.

Estados de las Landings

Una landing en Landinker puede estar en distintos estados:

• Borrador (Draft):

  • La landing está en edición.
  • No es pública.
  • Solo el equipo interno la puede ver.

• Publicada (Published):

  • La landing está activa y accesible en su URL pública.
  • Es visible para cualquier visitante.

• Archivada (Archived):

  • La landing queda guardada en el historial.
  • No es accesible públicamente.
  • Se puede restaurar a borrador o publicación si se necesita.

Paths de las Landings

Los paths son las rutas que determinan en qué URL vive cada landing.

• Se construyen a partir del slug definido en el editor.
• Ejemplo:
  • Landing con slug: oferta-2025
  • URL pública: https://tusitio.com/oferta-2025

Reglas

• Cada path debe ser único dentro de un mismo dominio.
• Los slugs no pueden usar rutas reservadas del sistema, porque Landinker las resuelve antes que tu landing y nunca se mostrarían: /api, /_next, /icon, /sitemap, /robots, /dashboard, /portal, /avatar, /og, /auth, /error, /invitation, y cualquier ruta que arranque con un archivo (/robots.txt, /sitemap.xml). El resto es tuyo: /terms, /privacy o /cookies son válidas en tu sitio.
• Los paths pueden actualizarse, pero cambiarlo implica actualizar también su URL pública.

Página 404 propia

Cuando alguien entra a una URL que no existe en tu sitio, la respuesta se queda en tu dominio (antes mandaba a landinker.com) y devuelve un 404 real.

Para personalizarla, creá una landing con el path /404 y publicala: pasa a ser la página de error de todo tu sitio. Si no definís ninguna, mostramos un 404 simple con los colores de tu paleta y un botón para volver al inicio.

La landing de /404 se sirve con status 404 (también si se entra directo a /404), que es lo que los buscadores esperan de una página de error.

Paths dinámicos

También podés crear paths dinámicos usando segmentos con :.

• Ejemplo de path dinámico: /producto/:categoria/:slug
• Si un usuario entra a /producto/zapatillas/nike-air, la landing se renderiza igual pero con variables disponibles dentro del contenido.
• Cada segmento dinámico se transforma en una variable en mayúsculas:
  • :categoria -> {{CATEGORIA}}
  • :slug -> {{SLUG}}
  • :idProducto -> {{IDPRODUCTO}}
  • :tag -> {{TAG}}

Vista previa con datos de ejemplo. Una landing dinámica no tiene un producto o una nota concretos hasta que alguien entra por una URL real. En el editor y en la vista previa del panel (el ojo de la lista de landings) esos componentes muestran un producto/nota de ejemplo, para que veas cómo va a quedar el diseño mientras la armás. Con una ruta fija (ej. una landing atada a un producto puntual) se muestran los datos reales de ese producto o nota.

Input guiado por tipo. En la configuración de la landing, por cada segmento :param aparece un selector con el tipo de variable (ID de producto, Categoría de producto, Slug de blog, Tag de blog o Personalizado). Al elegir un tipo conocido se usa el nombre canónico correcto (así no hay que tipearlo a mano) y se ofrece la resolución estricta que corresponde (productos o notas faltantes). Con "Personalizado" el nombre queda libre.

Cómo usarlos dentro del contenido

Podés insertar variables directamente en textos, títulos o descripciones usando llaves dobles:

• {{CATEGORIA}}
• {{SLUG}}
• {{CURRENT_PATH}}
• {{GROUP_NAME}}
• {{USER_NAME}}
• {{USER_EMAIL}}

Privacidad de {{USER_NAME}} y {{USER_EMAIL}}. Se completan con los datos del visitante logueado, pero solo si es miembro del grupo dueño de la landing (por seguridad, para no exponer los datos de un usuario de Landinker a landings de otros grupos). Para un visitante anónimo o de otro grupo quedan sin resolver: usá un fallback con | (ej. {{USER_NAME|invitado}}) para darles un valor por defecto.

Ejemplos prácticos

• Ruta fija: /black-friday
  • Sirve cuando la landing solo vive en una URL exacta.
• Ruta dinámica: /curso/:categoria/:slug
  • Sirve cuando querés reutilizar una misma landing para varias categorías o productos.
• Texto dentro de la landing: Explorá {{CATEGORIA}}: {{SLUG}}
  • Resultado de ejemplo: Explorá zapatillas: nike-air

Resolución de productos faltantes

En root props podés configurar strictProductResolution:

• false (recomendado para landing de marketing): si falta un producto, los bloques de producto faltantes se ocultan y la landing sigue renderizando.
• true (recomendado para landings de detalle): si falta un producto requerido, la landing se considera no encontrada y puede terminar en 404.

Esto es útil para decidir entre una experiencia tolerante a fallos o una experiencia estricta por URL de producto.

Historial de versiones

Cada vez que se guarda una landing (o se restaura una versión) se registra una versión en el historial, accesible desde el ícono de historial en el editor.

Desde el panel de historial podés:

• Nombrar/etiquetar una versión con un nombre propio (ej. "Antes del lanzamiento") para reconocerla de un vistazo. Se puede renombrar o quitar el nombre cuando quieras.
• Ver la vista previa de una versión tal como quedaría, antes de restaurarla.
• Comparar dos versiones: activá "Comparar versiones", elegí dos y vas a ver las diferencias — qué componentes se agregaron, se eliminaron o se modificaron, más los cambios de campos (nombre, estado, rutas).
• Restaurar una versión (desde la lista, la vista previa o la comparación). Al restaurar no se pisa el historial: se crea una nueva versión a partir de ese respaldo (el historial es append-only).

Nombrar y restaurar están disponibles para todas las entidades con historial (landings, productos y notas de blog). La comparación de componentes es propia de las landings (que tienen árbol de componentes).

Resumen

El Editor de Landings de Landinker permite:

• Construir páginas con componentes personalizables.
• Administrar su ciclo de vida con estados claros (borrador, publicada, archivada).
• Definir paths únicos que controlan la accesibilidad y visibilidad de cada landing.
• Resolver escenarios avanzados con paths dinámicos y módulos de producto enlazados por variables.