Landinker

Landing Editor

What is the Landing Editor?

The Landing Editor in Landinker is the visual tool that allows you to create, edit, and customize pages within the platform.
Its goal is to provide an intuitive and flexible experience, so that any user can build conversion-optimized landing pages without needing advanced technical knowledge.

How does it work?

• Each landing is composed of components (Navbar, Hero, Grid, etc.).
• Components have properties (props) that define their appearance and behavior.
• The editor lets you drag, drop, reorder, and configure components modularly.
• A landing can have different statuses (draft, published, archived).
• Each landing has a unique path that determines what URL it will be available at.

Note: This documentation explains the usage of the editor and its operating logic from the user's perspective. It does not include internal details of Puck's API.

Creating a landing

When creating a landing you can choose how to start:

• From a template: the page starts with pre-built sections (Hero, pricing, testimonials, footer, etc.) that you can edit freely.
• From scratch: a blank page to build block by block.

Templates are grouped by their purpose, and "From scratch" is always at the top. Templates that populate with your content indicate it on the card, so you know upfront if you need content preloaded.

Blog post: before publishing, choose which post it shows. If left unselected, the published page displays "Post not found" — in the editor, however, a sample post is shown. You can also bind it to a dynamic route parameter and have a single page serve all posts.

Catalog: the "Add to cart" button on each card is turned off by default, because it requires an active store (Pro and Enterprise plans). You can enable it from the component panel.

In either case, you then fill in basic details (name, paths, SEO) and proceed to the visual editor.

Properties (Props)

Properties are component-specific settings.
Examples:

• Colors (backgroundColor, textColor)
• Dimensions (height, width, borderRadius)
• Content (title, subtitle, items, src)
• Behavior (sticky, autoplay, required)

These properties allow customizing the landing in terms of design and functionality.

Components

Components are the building blocks of landings.

Categories

• Essentials: Navbar, Footer
• Sections: Hero, Features, Cta, Pricing, Testimonials, Stats, Steps, Team, LogoCloud, CountdownTimer
• Content: Card, FAQ, Accordion, Tabs
• Multimedia: Image, Video, Carousel, Gallery, BeforeAfter, Embed, Map
• Typography: HeadingBlock, Paragraph, List, IconText
• Actions: Button, Form, Newsletter, Social
• Products: ProductsGrid, ProductTitle, ProductPrice, ProductImage, ProductDescription, ProductCategory
• Blog: BlogIndex, BlogNote
• Structure: Container, Flex, Grid, Space, Divider

Components can be nested within containers (Container, Flex, Grid). To edit their properties with visual controls (color, spacing, dimensions, icons, and variables), see Edit components.

Product Components

Product modules allow you to:

• Display lists of products with ProductsGrid.
• Link individual blocks (ProductTitle, ProductPrice, ProductImage, ProductDescription, ProductCategory) to a specific product.
• Use a fixed productId (ObjectId) or dynamic (variable from the path).

When productId is dynamic, it is recommended to set paths with segments like :idProducto and use the resulting variable {{IDPRODUCTO}}.

Landing Statuses

A landing in Landinker can be in different statuses:

• Draft:

  • The landing is under editing.
  • It is not public.
  • Only the internal team can view it.

• Published:

  • The landing is active and accessible at its public URL.
  • It is visible to any visitor.

• Archived:

  • The landing is kept in history.
  • It is not publicly accessible.
  • It can be restored to draft or published if needed.

Landing Paths

Paths are the routes that determine what URL each landing lives at.

• Defined in the landing's settings.
• Example:
  • Path: /oferta-2025
  • Public URL: https://tusitio.com/oferta-2025

Rules

• Each path must be unique within the same domain.
• Paths cannot use system reserved routes, because Landinker resolves them before your landing and they would never be shown: /api, /_next, /icon, /sitemap, /robots, /dashboard, /portal, /avatar, /og, /auth, /error, /invitation, and any route starting with a file (/robots.txt, /sitemap.xml). The rest is yours: /terms, /privacy, or /cookies are valid on your site.
• Paths can be updated, but changing them also updates their public URL.

Custom 404 page

When someone visits a URL that does not exist on your site, the response stays on your domain (previously it redirected to landinker.com) and returns a real 404.

Your landings list already includes one, "Page not found (404)", marked as System: it is the error page for your entire site and is always published. Edit it like any landing — content, SEO, layout — and changes apply on save.

Being a system page, it cannot be deleted, unpublished, or have its route changed: it is the address your site looks for when a page doesn't exist. It also does not count toward your plan's landing limit. If you already had a custom landing at /404, it becomes this one: no duplicate is created.

The /404 landing is served with a 404 HTTP status (even when accessed directly at /404), which is what search engines expect for an error page.

Dynamic paths

You can also create dynamic paths using segments with :.

• Example dynamic path: /tienda/:categoria/:idProducto
• If a user visits /tienda/zapatillas/6770…-nike-air, the landing renders with variables available within the content.
• Each dynamic segment transforms into an uppercase variable:
  • :categoria -> {{CATEGORIA}}
  • :idProducto -> {{IDPRODUCTO}}
  • :nota -> {{NOTA}}
  • :tag -> {{TAG}}
• Product and post URLs include their identifier and name, like on Mercado Libre (/producto/6770691107212649a3077ddc-zapatillas-running). The page finds the product by identifier; the name is there for readability and Google. If you change the name, old links still work and redirect to the new name.

Preview with sample data. A dynamic landing has no concrete product or post until someone visits via a real URL. In the editor and dashboard preview (the eye icon on the landings list), these components show sample data so you can see how the design looks while building it. With a fixed route (e.g. a landing tied to a specific product), real data is displayed.

Guided type input. In the landing settings, for each :param segment a selector appears with the variable type (Product, Product Category, Blog Post, Blog Tag, or Custom). Choosing a known type uses the correct canonical name (avoiding manual typing) and provides appropriate strict resolution (missing products or posts). With "Custom", the name is freeform.

How to use variables inside content

You can insert variables directly into text, headings, or descriptions using double curly braces:

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

Privacy of {{USER_NAME}} and {{USER_EMAIL}}. They populate with data from the logged-in visitor, but only if they are a member of the group owning the landing (for security, avoiding exposure of Landinker user data to other groups' landings). For an anonymous visitor or one from another group, they remain unresolved: use a fallback with | (e.g. {{USER_NAME|guest}}) to provide a default value.

Practical examples

• Fixed route: /black-friday
  • Useful when the landing only lives at an exact URL.
• Dynamic route: /curso/:categoria
  • Useful when you want to reuse the same landing for multiple categories.
• Text within landing: Explore {{CATEGORIA}}
  • Example result: Explore sneakers

Handling missing products

In root props you can configure strictProductResolution:

• false (recommended for marketing landings): if a product is missing, missing product blocks are hidden and the landing continues rendering.
• true (recommended for detail landings): if a required product is missing, the landing is treated as not found and can return a 404.

This is useful for choosing between a fault-tolerant experience or a strict URL-based product experience.

Version history

Each time a landing is saved (or a version is restored), a version is recorded in history, accessible via the history icon in the editor.

From the history panel you can:

• Name/label a version with a custom name (e.g. "Before launch") to recognize it at a glance. You can rename or remove the label anytime.
• Preview a version as it would look before restoring it.
• Compare two versions: enable "Compare versions", select two, and see the differences — which components were added, removed, or modified, plus field changes (name, status, paths).
• Restore a version (from list, preview, or comparison). Restoring does not overwrite history: a new version is created from that backup (history is append-only).

Naming and restoring are available for all entities with history (landings, products, and blog posts). Component comparison is exclusive to landings (which have a component tree).

Summary

The Landinker Landing Editor allows:

• Building pages with customizable components.
• Managing their lifecycle with clear statuses (draft, published, archived).
• Defining unique paths that control accessibility and visibility for each landing.
• Resolving advanced scenarios with dynamic paths and product modules linked via variables.