La ficha básica informa. La avanzada convence. Ocho patrones que transforman un ProductLayout estándar en una página de venta técnica para compradores B2B: posicionamiento narrativo, datos operativos, configurador visual y cierre con FAQ voz de operador.
Los patrones de esta guía se destilaron del análisis de las mejores fichas del portafolio: páginas de EPP técnico, maquinaria industrial y equipamiento normado donde el comprador es un profesional que decide con datos —no con precio—. Son ocho patrones distintos que se pueden usar por separado o combinados, según el producto y el sector.
El punto de referencia real que los inspiró: la ficha del Globe G-XTREME 3.0 en FIREFIGHTERMX — 1,464 líneas de Astro que documentan qué tan lejos puede llegar una página de producto en el mercado B2B técnico mexicano. Esta guía lo disecciona patrón por patrón y lo hace replicable.
Definición
Una ficha de producto L4 que va más allá del hero + specs + sidebar básico. Estructura el argumento de venta técnico completo: posicionamiento, evidencia, configuración, métricas operativas, comparación y cierre con FAQ voz del comprador real.
La ficha básica (ProductLayout + bloques opcionales) resuelve el 80% de los productos de un catálogo. La ficha avanzada existe para el otro 20%: productos de alto valor, técnicamente complejos, con comprador profesional y ciclo de venta largo. No es un layout distinto — es el mismo Astro con datos más ricos, estructura de argumento deliberada y ocho patrones específicos que transforman la página en lo que un vendedor técnico haría en una presentación presencial.
El criterio de uso es la proporcionalidad entre el peso del argumento y el precio de la decisión. Un producto de 200 MXN no necesita un hero narrativo de 500 palabras. Un traje estructural de 80,000 MXN que va a un proceso de licitación sí. La regla: si para vender el producto haría falta una presentación técnica, la ficha avanzada es esa presentación en formato web.
Función e importancia
Elimina la necesidad de una presentación técnica previa: el visitor B2B llega a WhatsApp ya informado, ya convencido y con los datos que necesita para justificar la compra internamente. El tiempo de cotización baja; la tasa de cierre sube.
El comprador técnico llega a una ficha básica, no encuentra los datos que necesita, pide la ficha técnica al vendedor y el proceso se alarga 5 días. La ficha avanzada elimina ese ciclo: los datos operativos, la comparativa, las objeciones y la configuración ya están — el vendedor recibe un lead que ya sabe lo que quiere.
Su segundo trabajo es la diferenciación por información. En muchos mercados técnicos B2B mexicanos, el competidor no publica TPP ni THL, no tiene timeline de evolución del producto, no explica qué significa una certificación en campo real. La ficha avanzada convierte la transparencia técnica en argumento de venta visible y rastreable por buscadores.
Un comprador técnico (director de cuerpo, encargado de licitación, gerente industrial) llega con preguntas muy específicas: ¿cuánto TPP tiene? ¿qué generación es? ¿cuál variante para mi perfil? La ficha avanzada responde todo eso antes de que él tenga que preguntar. El lead que llega a WhatsApp ya sabe lo que quiere — el tiempo de cotización baja a la mitad.
Una ficha de traje estructural de 80,000 MXN no puede tener el mismo nivel de profundidad que un accesorio de 200 pesos. El peso del argumento debe ser proporcional al precio de la decisión. La ficha avanzada es el equivalente digital de una presentación de ventas técnica: estructura el argumento en el orden correcto (posicionamiento → evidencia → specs → comparación → cierre).
El hero narrativo + la terminología técnica precisa captura búsquedas de alta intención («Globe G-XTREME 3.0 precio México», «traje NFPA 1971-2018 TPP 42 distribuidor»). El FAQ voz operador captura las preguntas de comparación («G-XTREME vs ATHLETIX», «traje bombero PFAS-free México»). Y el formulario WhatsApp integrado convierte la sesión en un lead cualificado sin que el visitante tenga que abrir otra app.
Anatomía · 8 patrones
Ocho bloques específicos que se suman al ProductLayout base según el producto y el sector. No todos se usan juntos: se combinan los que resuelven un problema real del comprador de ese producto.
Cada patrón resuelve una pregunta específica del comprador técnico. P1 (hero narrativo): «¿es este el producto que usan los referentes del sector?». P2 (strip): «¿qué tiene a primera vista, sin leer?». P3 (apertura): «¿por qué lo elegirían sobre el genérico?». P4 (timeline): «¿cuánta madurez tiene el producto?». P5 (configurador): «¿cuál variante es para mi caso?». P6 (métricas): «¿qué significa ese número en campo real?». P7 (sidebar 6W): «¿dónde está el botón de compra mientras leo?». P8 (FAQ + form): «¿ya se respondió mi objeción y puedo cotizar ahora mismo?».
La regla de uso es la proporcionalidad y la honestidad. Solo usas el timeline si el producto tiene versiones reales con cambios sustanciales. Solo usas el configurador si hay variantes reales. Solo usas la traducción operativa de métricas si las entiendes y las puedes explicar con precisión. Cada patrón bien ejecutado agrega; mal ejecutado, resta credibilidad.
El hero no describe el producto: lo posiciona. La apertura es el dato social más poderoso («el caballo de batalla de FDNY y LAFD»), no la ficha técnica. Los stats clave (TPP/THL, índice de rendimiento, capacidad máxima) van como tarjetas dentro del hero, no enterrados en la tabla de especificaciones. El visitante sabe en 5 segundos qué está mirando y por qué importa.
Dato h1: posicionamiento (no nombre técnico) · stats inline como <div> cards dentro del hero · badges: nivel, marca, origen, diferenciador clave
Una banda horizontal de 6 ítems justo debajo del hero: los datos más consultados en el pre-decisión (material, opciones, barrera, liner, patronaje, origen). El visitante los escanea en 3 segundos antes de comprometerse a leer. Diferente a la tabla de especificaciones completa (que está más abajo): el strip es para reconocimiento, la tabla es para verificación.
Dato grid 2col mobile / 6col desktop · [label + value] data-driven · bg-white border-b · posición: section inmediata después del hero
La primera sección del cuerpo principal no es "Descripción técnica". Es la historia del producto en boca del sector: quién lo usa, por qué lo elige y qué hace que ese patrón se repita durante más de una década. Incluye evidencia social concreta (nombres de departamentos, no categorías genéricas). El argumento va de lo narrativo a lo técnico, no al revés.
Dato eyebrow: "El traje detrás del símbolo" · h2: por qué lo eligen · 3 párrafos: datos publicados, configurabilidad, cadena de suministro · sin specs en este punto
Para productos con versiones o generaciones (3.0, v2, segunda edición), un timeline vertical responde la pregunta "¿esto es nuevo o lleva años?" con precisión. Cada nodo: versión + año + cambio clave. El nodo actual resaltado en color primario. Comunica madurez del producto (no está en beta) y evolución documentada (no promesas).
Dato TIMELINE_ITEMS[] = { version, año, cambio, actual? } · línea vertical SVG/gradiente · nodo actual: fondo primario · renderizado desde array data-driven
Cuando el producto tiene variantes configurables (materiales, planes, modelos), un grid de cards evita que el visitante tenga que pedir asesoría técnica para elegir. Cada card: nombre, especificación técnica, descripción, "Ideal para" y badge de categoría. La variante estándar resaltada. Embedded al final: "¿No sabes cuál elegir? Empieza con X." — elimina la parálisis de decisión.
Dato VARIANTES[] = { nombre, spec, descripcion, ideal, badge, badgeColor } · grid 2col · card[0] border-primary (estándar) · callout "¿No sabes cuál?"
Las métricas técnicas (TPP, THL, IPX4, clase de aislamiento) no se comunican solas: el visitante no sabe si 42 cal/cm² es bueno o excelente ni qué implica en operación real. La traducción tiene tres partes: (1) valor y mínimo normativo + margen, (2) qué mide en lenguaje no técnico, (3) cómo se traduce en la realidad del operador. Disclaimer de fuente al pie.
Dato METRICAS[] = { metrica, valor, minimo, margen, significado, traduccion } · header dark con número grande · badge de margen en verde · disclaimer de fuente
El sidebar básico tiene 2 widgets (cotizar + relacionados). El avanzado tiene 6: (W1) cotización dark destacada con WhatsApp + formulario, (W2) ficha rápida con stats grandes, (W3) modelos relacionados con badge de nivel, (W4) sectores aplicables con links, (W5) blog técnico relacionado, (W6) widget de marca (historia + link a página de marca). Cada widget es sticky en desktop.
Dato W1-W6 renderizados desde arrays data-driven · lg:sticky lg:top-[header+24px] · espacio-y-5 entre widgets · W6 con borde de color primario y gradient top line
El FAQ no es "Preguntas frecuentes" genéricas: es "Las preguntas que el operador hace antes de aceptar un equipo nuevo". Cada ítem tiene: categoría (Reputación, Cifras técnicas, Decisión de compra, Mantenimiento…), pregunta en voz del comprador real y respuesta honesta. Dentro de cada respuesta: link "Profundizar por WhatsApp" contextualizado. Al lado derecho: formulario que construye el mensaje WA con los datos relevantes (cantidad, variante, tipo de solicitud) y lo abre en WhatsApp.
Dato FAQ_ITEMS[] con categoría · <details> accordion · link WA dentro de respuesta · formulario derecho: campos relevantes → JS construye msg → window.open(wa.me)
Variantes por sector
Los ocho patrones se combinan distinto según el sector y el tipo de producto. Cinco perfiles reales con las combinaciones más comunes.
No existe una «ficha avanzada universal». Un producto técnico normado usa P1+P2+P6 (hero narrativo + strip + métricas); un producto configurable usa P5 (configurador); uno con historial usa P4 (timeline); una licitación usa P8 diferenciado (3 CTAs). Lo que sí es universal es la lógica: el patrón se usa cuando resuelve una pregunta real del comprador del sector.
Abajo, cinco perfiles reales con las combinaciones de patrones que han demostrado funcionar en el portafolio. Para cada perfil: el caso de uso, los patrones que aplican y el diferenciador central.
Responsive y móvil
Dos patrones críticos: el sidebar de 6 widgets se apila bajo el contenido (no hay sticky en móvil) y el hero narrativo colapsa los stats a una columna con los botones a full-width. El formulario WA usa font-size: 16px en inputs para evitar el zoom de iOS.
El hero con stats inline va de 2 columnas (texto + imagen) a 1 columna apilada en móvil, con los stats como grid de 2x2 y los botones a ancho completo. El strip de specs pasa de 6 ítems en fila a 2x3 o 3x2 según el breakpoint. El sidebar sticky deja de ser sticky y se apila al final del contenido — en móvil la prioridad es el contenido, no la conversión lateral.
El formulario WhatsApp tiene una regla crítica de iOS: los campos de texto y select necesitan font-size: 16px mínimo para que el teléfono no haga zoom automático al hacer focus. Ese zoom desorienta al usuario y causa abandonos. La regla aplica solo a inputs/select/textarea, no al resto del layout.
El hero narrativo va de texto+imagen en paralelo a una sola columna apilada. Los stats inline pasan de 2 tarjetas lado a lado a grid 2×2. Los botones de CTA pasan a full-width en orden de prioridad (cotizar primero).
.hero-grid {
display: grid;
grid-template-columns: 1fr;
gap: var(--sp-8);
}
@media (min-width: 1024px) {
.hero-grid { grid-template-columns: 1.05fr 0.95fr; }
}
.stats-inline {
display: grid;
grid-template-columns: 1fr 1fr;
gap: var(--sp-3);
max-width: 28rem;
}
@media (max-width: 640px) {
.hero__actions .btn { width: 100%; }
}En iOS, cualquier input con font-size menor a 16px hace zoom automático al hacer focus. En una ficha B2B ese zoom desorienta y causa abandono. Todos los input, select y textarea llevan style='font-size:16px'.
<!-- Evita el zoom automático de iOS en todos los campos del formulario -->
<!-- No es suficiente el CSS externo: requiere el atributo style inline -->
<input type="text" name="nombre" style="font-size:16px;" placeholder="Tu nombre" />
<input type="tel" name="telefono" style="font-size:16px;" inputmode="tel" />
<input type="email" name="email" style="font-size:16px;" inputmode="email" />
<select name="cantidad" style="font-size:16px;"> ... </select>
<textarea name="mensaje" style="font-size:16px;" rows="3"></textarea>Posición en el sitio
En src/pages/productos/[categoria]/[slug].astro — la misma ruta dinámica del ProductLayout básico. La diferencia es el contenido de la página: un MODELO {} más rico, arrays de datos adicionales (TIMELINE, VARIANTES, METRICAS, FAQ_ITEMS, BLOG_RELACIONADO, SECTORES) y el HTML correspondiente a los 8 patrones.
Técnicamente es la misma página que la ficha básica, generada por la misma ruta [...slug].astro. La diferencia está en el template que esa ruta llama: para productos de alto valor con todos los datos, puede crear un layout específico (TechnicalProductLayout o SectorLayout) que encapsula los 8 patrones y recibe los arrays de datos como props. Para el portafolio con múltiples sectores (bomberos, construcción, seguridad), lo práctico es una página .astro hardcoded por producto —igual que FIREFIGHTERMX— que reutiliza los componentes del sistema pero no depende de una Content Collection con todos los campos posibles.
La decisión entre ruta dinámica y página hardcoded es de escala. Para 5-10 productos de alto valor en un sector, la página específica es más fácil de mantener y más flexible. Para 50+ productos donde la estructura es la misma, un layout genérico con todos los props opcionales escala mejor. Esta guía documenta los patrones; cómo estructurarlos depende del catálogo real.
Implementación
Seis recetas: P1 hero narrativo + stats inline, P2 strip de specs rápidas, P4 timeline evolutivo, P5 configurador de variantes, P6 traducción operativa de métricas, P7 sidebar de 6 widgets, P8 formulario WhatsApp con JS y schema avanzado (Product + FAQPage + additionalProperty).
Cada receta es independiente: se puede copiar y aplicar sin necesitar las demás. El patrón de datos siempre es el mismo — un array const [] = [...] definido en el frontmatter .astro, mapeado con .map() en el template. Eso hace que las fichas avanzadas sean data-driven aunque no dependan de una Content Collection.
La receta del formulario WhatsApp incluye el JS de submit: el único JavaScript del sistema que no puede ir en un componente Astro reutilizable fácilmente —porque necesita el waNumber y el nombre del modelo del contexto de esa ficha específica—. Se puede extraer a un módulo JS importado como <script> con parámetros data-* en el formulario.
<!-- P1 · Hero con stats inline — los números dentro del hero -->
<!-- Los stats NO van en la tabla de specs: van en el hero como tarjetas -->
<section class="gradient-tactical">
<div class="container-page py-12 lg:py-20">
<div class="grid grid-cols-1 lg:grid-cols-[1.05fr_0.95fr] gap-10">
<div>
<!-- Badges contextuales: nivel, marca, origen, diferenciador -->
<div class="flex flex-wrap gap-2 mb-5">
<span class="badge-nivel">{MODELO.nivel}</span>
<span class="badge-marca">{MODELO.marcaNombre} · {MODELO.marcaSlugFull}</span>
<span class="badge-origen">Made in USA</span>
<span class="badge-diferenciador">5 outer shells</span>
</div>
<!-- H1 como posicionamiento, no como nombre técnico -->
<h1>
{MODELO.nombre}
<span class="subtitulo-h1">
El caballo de batalla · NFPA 1971-2018 · UL Classified
</span>
</h1>
<!-- Stats como TARJETAS dentro del hero (no en la tabla de abajo) -->
<div class="grid grid-cols-2 gap-3 mb-6 max-w-md">
<div class="stat-card">
<p class="stat-label">TPP reportado</p>
<p class="stat-valor">42 <span>cal/cm²</span></p>
<p class="stat-sub">Mínimo NFPA: 35 · margen +20%</p>
</div>
<div class="stat-card">
<p class="stat-label">THL reportado</p>
<p class="stat-valor">266 <span>W/m²</span></p>
<p class="stat-sub">Mínimo NFPA: 205 · margen +30%</p>
</div>
</div>
<!-- 3 CTAs diferenciados por momento del ciclo de compra -->
<div class="flex flex-wrap gap-3">
<a href={waUrl(msgCotizar)} class="btn btn-primary">Cotizar por WhatsApp</a>
<a href={waUrl(msgFicha)} class="btn btn-ghost">Ficha técnica + comparativo</a>
<!-- Tercer CTA visible solo en fichas con perfil de licitación -->
<!-- <a href={waUrl(msgLicitacion)} class="btn btn-ghost">Solicitar paquete licitación</a> -->
</div>
</div>
<!-- Imagen con badges flotantes (UL badge circular, versión badge) -->
<div class="relative">
<img src={MODELO.imagen} alt="{descripción larga con palabras clave}" ... />
<div class="absolute top-4 right-4 badge-certificacion">
<span>UL</span><span>Classified</span>
</div>
<div class="absolute top-4 left-4 badge-version">Gen 3.0 · Actual</div>
</div>
</div>
</div>
</section><!-- P2 · Strip de specs rápidas — 6 ítems bajo el hero -->
<!-- Diferente a la tabla completa: es para reconocimiento, no verificación -->
<section class="bg-white border-b">
<div class="container-page py-6">
<div class="grid grid-cols-2 md:grid-cols-4 lg:grid-cols-6 gap-4">
{[
{ label: 'Exterior', value: 'PBI Max 7.0 oz' },
{ label: 'Opciones outer', value: '5 configurables' },
{ label: 'Barrera humedad', value: 'CROSSTECH® Black' },
{ label: 'Barrera térmica', value: 'Caldura SL2i' },
{ label: 'Patronaje', value: 'AXTION Back · raglán' },
{ label: 'Origen', value: 'Made in NH · USA' },
].map((s) => (
<div class="text-center md:text-left">
<p class="text-[10px] font-bold uppercase tracking-widest text-ink-500">{s.label}</p>
<p class="text-sm font-display font-bold text-ink-900 leading-tight">{s.value}</p>
</div>
))}
</div>
</div>
</section>
<!-- REGLA: máximo 6 ítems · los más consultados antes de comprometerse a leer
la ficha completa. Material principal, variantes disponibles, tecnología
clave, origen/fabricación. No repetir lo que ya está en el hero. --><!-- P4 · Timeline evolutivo — generaciones del producto -->
const TIMELINE = [
{ version: 'G-XTREME 1.0', año: '~ 2008', cambio: 'Lanzamiento...', actual: false },
{ version: 'G-XTREME 2.0', año: '~ 2015', cambio: 'Refinamiento...', actual: false },
{ version: 'G-XTREME 3.0', año: '2020+', cambio: 'Generación actual...', actual: true },
]
<!-- Renderizado: línea vertical + nodos -->
<div class="relative">
<!-- Línea vertical SVG o div -->
<div class="absolute left-[19px] top-2 bottom-2 w-[2px]
bg-gradient-to-b from-primary via-primary/40 to-border"
aria-hidden="true"></div>
<div class="space-y-6">
{TIMELINE.map((step) => (
<div class="flex gap-5">
<!-- Nodo: círculo; actual = fondo primario, pasado = borde gris -->
<span class={`nodo ${step.actual ? 'nodo--actual' : 'nodo--pasado'}`}>
{step.version.includes('3.0') ? '03' : step.version.includes('2.0') ? '02' : '01'}
</span>
<!-- Card: actual = borde primario + sombra, pasado = borde base -->
<div class={`card ${step.actual ? 'card--actual' : 'card--base'}`}>
<div class="flex items-baseline gap-3">
<h3>{step.version}</h3>
<span class="año">{step.año}</span>
{step.actual && <span class="badge-actual">Generación actual</span>}
</div>
<p>{step.cambio}</p>
</div>
</div>
))}
</div>
</div><!-- P5 · Configurador de variantes — grid de cards por opción -->
const VARIANTES = [
{ nombre: 'PBI Max', spec: '7.0 oz/yd²', badge: 'Estándar', badgeColor: 'red',
descripcion: 'El estándar histórico del G-XTREME...',
ideal: 'Dotación municipal estándar · alta frecuencia · presupuesto medio' },
{ nombre: 'Pioneer', spec: 'Filamento Kevlar/Nomex', badge: 'Resistencia', badgeColor: 'ink',
descripcion: 'Filamento técnico de alta resistencia a abrasión...',
ideal: 'USAR · rescate técnico · abrasión severa' },
// ... 3 variantes más
]
<div class="grid grid-cols-1 md:grid-cols-2 gap-4">
{VARIANTES.map((v, i) => (
<!-- Primera card (estándar) lleva borde primario y sombra -->
<div class={`card ${i === 0 ? 'card--destacada' : 'card--base'}`}>
<div class="flex items-start justify-between gap-3">
<div>
<h3>{v.nombre}</h3>
<p class="spec font-mono">{v.spec}</p>
</div>
<span class={`badge badge--${v.badgeColor}`}>{v.badge}</span>
</div>
<p class="descripcion">{v.descripcion}</p>
<div class="border-t pt-3 mt-4">
<p class="label-ideal">Ideal para</p>
<p class="valor-ideal">{v.ideal}</p>
</div>
</div>
))}
</div>
<!-- Callout "¿No sabes cuál elegir?" — elimina la parálisis de decisión -->
<div class="callout-info mt-6">
<p><strong>¿No sabes cuál elegir?</strong></p>
<p>Empieza con <strong>PBI Max 7.0 oz/yd² estándar</strong>. Es la configuración
por la que se hizo famoso el modelo. Las opciones se ofrecen sin cambio de precio
base — el upgrade se factura por costo diferencial, no por cambio de modelo.</p>
</div><!-- P6 · Traducción operativa de métricas -->
const METRICAS = [
{
metrica: 'TPP',
valor: '42 cal/cm²',
minimo: '35 cal/cm²',
margen: '+20%',
significado: 'Thermal Protective Performance — energía térmica resistida antes de quemadura de 2º grado',
traduccion: 'Varios segundos adicionales bajo flujo radiante alto vs el mínimo NFPA. La diferencia que importa cuando hay flashover.',
},
{
metrica: 'THL',
valor: '266 W/m²',
minimo: '205 W/m²',
margen: '+30%',
significado: 'Total Heat Loss — capacidad del traje de eliminar el calor metabólico del operador al ambiente',
traduccion: 'Diferencia que se siente en las horas 4–6 de un incendio prolongado, no en los primeros 5 minutos.',
},
]
{METRICAS.map((m) => (
<div class="card-metrica">
<!-- Header oscuro: número grande + mínimo NFPA + badge de margen -->
<div class="header-dark">
<p class="metrica-label">{m.metrica}</p>
<div class="valor-row">
<span class="valor-grande">{m.valor.split(' ')[0]}</span>
<span class="valor-unidad">{m.valor.split(' ').slice(1).join(' ')}</span>
</div>
<div class="meta-row">
<span>Mínimo NFPA: <strong>{m.minimo}</strong></span>
<span class="badge-margen badge--success">{m.margen}</span>
</div>
</div>
<!-- Body: qué mide + cómo se traduce en operación -->
<div class="body-metrica">
<p class="label-seccion">Qué mide</p>
<p>{m.significado}</p>
<p class="label-seccion">Cómo se traduce en operación</p>
<p class="traduccion">{m.traduccion}</p>
</div>
</div>
))}
<!-- SIEMPRE incluir disclaimer de fuente al pie de la sección de métricas -->
<p class="disclaimer">
Cifras reportadas por el fabricante en literatura técnica pública. Validadas por
entidad independiente. Solicitar confirmación documental para licitaciones con
auditoría rigurosa.
</p><!-- P7 · Sidebar avanzado — 6 widgets vs. sidebar básico cotizar+llamar -->
<!-- W1 · Cotización dark destacada -->
<div class="sidebar-widget sidebar-widget--dark">
<p class="widget-label">¿Listo para cotizar?</p>
<p class="widget-title">Respuesta en menos de 2 horas hábiles</p>
<a href={waUrl(msgCotizar)} class="btn-wa">WhatsApp directo</a>
<a href="/contacto" class="btn-formulario">Formulario de contacto</a>
<p class="widget-horario">Lun–Vie 9:00 a 18:00 · {CONTACT.whatsappDisplay}</p>
</div>
<!-- W2 · Ficha rápida con STATS DESTACADOS arriba -->
<div class="sidebar-widget">
<!-- Stats primero — lo que el buyer técnico quiere ver de inmediato -->
<div class="stats-grid">
<div class="stat-mini"><span>TPP</span><strong>42</strong><span>cal/cm²</span></div>
<div class="stat-mini"><span>THL</span><strong>266</strong><span>W/m²</span></div>
</div>
<!-- Luego los datos secundarios en lista key-value -->
<dl class="ficha-rapida">
<dt>Fabricante</dt><dd>{MODELO.marcaNombre}</dd>
<dt>Grupo</dt><dd>MSA Safety (NYSE)</dd>
<dt>Origen</dt><dd>Pittsfield, NH · USA</dd>
<dt>Variantes</dt><dd>5 outer shells configurables</dd>
<dt>Norma</dt><dd>NFPA 1971-2018</dd>
<dt>Validación</dt><dd>UL Classified</dd>
<dt>Entrega</dt><dd>60–90 días hábiles</dd>
</dl>
</div>
<!-- W3 · Modelos relacionados con badge de nivel -->
<div class="sidebar-widget">
<ul>
{MODELOS_RELACIONADOS.map((m) => (
<li>
<a href={href(m)}>
<div>
<p class="related-nombre">{m.nombre}</p>
<p class="related-marca">{m.marca}</p>
</div>
<span class={`badge-nivel badge-nivel--${m.nivel}`}>
{m.nivel === 'Ultra Premium' ? 'Ultra' : 'Premium'}
</span>
</a>
</li>
))}
</ul>
<a href="/productos/[categoria]">Ver catálogo completo →</a>
</div>
<!-- W4 · Sectores aplicables con links -->
<div class="sidebar-widget">
<ul>
{SECTORES.map((s) => (
<li><a href={`/sectores/${s.slug}`}>→ {s.label}</a></li>
))}
</ul>
</div>
<!-- W5 · Blog técnico relacionado -->
<div class="sidebar-widget">
<ul>
{BLOG_RELACIONADO.map((b) => (
<li><a href={`/blog/${b.slug}`}>{b.titulo} →</a></li>
))}
</ul>
</div>
<!-- W6 · Widget de marca — historia + link a página de marca -->
<div class="sidebar-widget sidebar-widget--brand">
<p class="widget-label">Sobre la marca</p>
<h3>{MODELO.marcaNombre}</h3>
<p>{TEXTO_MARCA}</p>
<a href={`/marcas/${MODELO.marcaSlug}`}>Ver página de {MODELO.marcaNombre} →</a>
</div><!-- P8 · Formulario WhatsApp — construye el mensaje y lo abre -->
<!-- Los campos deben ser LOS RELEVANTES para el sector, no genéricos -->
<form id="wa-form-producto" data-wa-number={CONTACT.whatsapp}
data-modelo={MODELO.nombre} data-cert="NFPA 1971-2018 · UL Classified">
<!-- Campos base: quién y de dónde -->
<input name="nombre" placeholder="Tu nombre" required />
<input name="corporacion" placeholder="Corporación" required />
<input name="telefono" placeholder="55 0000 0000" required type="tel" />
<input name="email" placeholder="correo@empresa.mx" type="email" />
<!-- Campos ESPECÍFICOS del producto — aquí está el valor del formulario -->
<select name="cantidad">
<option value="1–5 unidades">1 a 5 unidades</option>
<option value="6–20 unidades">6 a 20 unidades</option>
<option value="21–50 unidades">21 a 50 unidades</option>
<option value="+50 unidades (brigada completa)">+50 (brigada completa)</option>
</select>
<select name="variante">
{VARIANTES.map((v) => <option value={v.nombre}>{v.nombre}</option>)}
<option value="Asesoría para elegir">Asesoría para elegir</option>
</select>
<!-- Tipo de solicitud: pre-cualifica el lead sin preguntar en WA -->
<select name="tipo">
<option value="Cotización general">Cotización general con disponibilidad y precio</option>
<option value="Ficha técnica">Ficha técnica + comparativo de variantes</option>
<option value="Licitación pública">Cotización formal para licitación pública</option>
<option value="Asesoría técnica">Asesoría técnica previa a compra</option>
</select>
<textarea name="mensaje" placeholder="Perfil de respuesta, fecha objetivo, presupuesto…" />
<button type="submit">Enviar por WhatsApp →</button>
</form>
<script>
const form = document.getElementById('wa-form-producto') as HTMLFormElement
form?.addEventListener('submit', (e) => {
e.preventDefault()
const d = new FormData(form)
const get = (k: string) => (d.get(k) || '').toString().trim()
// Construye el mensaje estructurado — el vendedor recibe contexto completo
let txt = `Hola, soy *${get('nombre')}* de *${get('corporacion')}*.\n\n`
txt += `🔥 *Modelo de interés:* ${form.dataset.modelo}\n`
txt += `📋 *Certificación:* ${form.dataset.cert}\n`
txt += `🛒 *Solicitud:* ${get('tipo')}\n`
if (get('cantidad')) txt += `📦 *Cantidad:* ${get('cantidad')}\n`
if (get('variante')) txt += `⚙️ *Variante:* ${get('variante')}\n`
txt += `📞 *Teléfono:* ${get('telefono')}\n`
if (get('email')) txt += `✉️ *Correo:* ${get('email')}\n`
if (get('mensaje')) txt += `\n📝 *Detalles:*\n${get('mensaje')}\n`
txt += '\nQuedo a la espera de su cotización. Gracias.'
window.open(`https://wa.me/${form.dataset.waNumber}?text=${encodeURIComponent(txt)}`, '_blank', 'noopener')
})
</script>
<!-- REGLA: los campos del formulario deben ser ESPECÍFICOS para el sector.
Un formulario genérico (nombre + mensaje) no aporta sobre el botón WA directo.
El valor está en pre-cualificar: cantidad, variante, tipo de solicitud.
Convención: style="font-size:16px" en inputs para evitar zoom en iOS. --><!-- Schema avanzado para fichas de producto premium (más allá de Product básico) -->
<script type="application/ld+json" set:html={JSON.stringify({
'@context': 'https://schema.org',
'@type': 'Product',
name: `${MODELO.nombre} · Categoría · Norma`,
description: MODELO.descripcionCorta,
image: [absoluteUrl(MODELO.imagen)],
brand: buildBrandSchema(MODELO.marcaSlug), // {Name, @type, sameAs}
manufacturer: buildManufacturerSchema(MODELO.marcaSlug),
category: MODELO.categoriaTitulo,
sku: MODELO.sku,
countryOfOrigin: { '@type': 'Country', name: 'United States of America' },
url: canonical,
// additionalProperty — los datos técnicos para rich results y AI search
additionalProperty: [
{ '@type': 'PropertyValue', name: 'Material exterior', value: 'PBI Max 7.0 oz/yd²' },
{ '@type': 'PropertyValue', name: 'TPP reportado', value: '42 cal/cm²' },
{ '@type': 'PropertyValue', name: 'THL reportado', value: '266 W/m²' },
{ '@type': 'PropertyValue', name: 'Certificación', value: 'NFPA 1971-2018 · UL Classified' },
],
// isRelatedTo — conecta las fichas del mismo catálogo en el grafo
isRelatedTo: MODELOS_RELACIONADOS.slice(0, 4).map((m) => ({
'@type': 'Product',
'@id': absoluteUrl(`/productos/[categoria]/${m.slug}`),
name: m.nombre,
})),
// audience — para quién es el producto (útil en búsqueda B2B)
audience: {
'@type': 'Audience',
audienceType: 'Cuerpos de bomberos · brigadas industriales · gobierno · licitaciones',
geographicArea: { '@type': 'Country', name: 'México' },
},
// offers — con shippingDetails para rich results de entrega
offers: {
'@type': 'Offer',
availability: 'https://schema.org/PreOrder',
priceCurrency: 'MXN',
priceSpecification: { '@type': 'PriceSpecification', priceCurrency: 'MXN' },
seller: { '@id': `${SITE.url}/#organization` },
itemCondition: 'https://schema.org/NewCondition',
url: canonical,
// MerchantReturnPolicy — obligatorio para eligibilidad de rich results
hasMerchantReturnPolicy: {
'@type': 'MerchantReturnPolicy',
applicableCountry: 'MX',
returnPolicyCategory: 'https://schema.org/MerchantReturnFiniteReturnWindow',
merchantReturnDays: 15,
},
// shippingDetails — comunica el plazo de entrega en el schema
shippingDetails: {
'@type': 'OfferShippingDetails',
shippingDestination: { '@type': 'DefinedRegion', addressCountry: 'MX' },
deliveryTime: {
'@type': 'ShippingDeliveryTime',
handlingTime: { '@type': 'QuantitativeValue', minValue: 0, maxValue: 5, unitCode: 'DAY' },
transitTime: { '@type': 'QuantitativeValue', minValue: 60, maxValue: 90, unitCode: 'DAY' },
},
},
},
})} is:inline />
<!-- FAQPage schema — SIEMPRE en las fichas con FAQ voz operador -->
<script type="application/ld+json" set:html={JSON.stringify({
'@context': 'https://schema.org',
'@type': 'FAQPage',
mainEntity: FAQ_ITEMS.map((f) => ({
'@type': 'Question',
name: f.pregunta,
acceptedAnswer: { '@type': 'Answer', text: f.respuesta },
})),
})} is:inline />Las ocho recetas son modulares: puedes combinar solo las que tu producto necesita. El orden de implementación recomendado: P1 (hero narrativo) y P8 (FAQ + formulario) primero — tienen el mayor impacto en conversión. P2 (strip) y P7 (sidebar 6W) segundo — mejoran el escaneo y el cierre. P4, P5, P6 tercero — según si el producto tiene versiones, variantes y métricas normativas que documentar.
El schema avanzado (última receta) se implementa junto con P1 — la información del hero
narrativo y los stats inline son exactamente los datos que van en additionalProperty
y en offers.shippingDetails. Nunca pongas datos de relleno en el schema:
si no tienes el plazo de entrega exacto, omite shippingDetails en lugar de
inventar un número.
Buenas prácticas
Ocho hábitos que hacen de la ficha avanzada un argumento de venta honesto y efectivo; ocho errores que la convierten en ruido visual o, peor, en contenido que pierde credibilidad ante el comprador técnico.
La ficha avanzada es efectiva cuando cada patrón resuelve un problema real del comprador del sector. Es contraproducente cuando los patrones se usan «porque sí» o con datos de relleno. Un timeline sin versiones reales, un configurador con variantes inventadas o una traducción de métricas que no se entiende son peores que no tener esas secciones.
Los no son los antipatrones más frecuentes del portafolio: hero narrativo sin dato verificable, strip con datos repetidos del hero, timeline de 2 versiones donde la diferencia es «mejora de rendimiento», formulario WA con campos genéricos que no pre-cualifican nada. Léelos como checklist antes de lanzar la ficha.
Cuando el precio de la decisión es alto y el comprador es técnico. La ficha básica funciona para productos de compra rápida (catálogo, accesorio, consumible). La avanzada se justifica cuando el visitante necesita comparar, verificar y argumentar la compra internamente antes de contactar — productos de 10,000 MXN o más, licitaciones, equipamiento técnico normado. La regla de oro: si el vendedor tendría que hacer una presentación técnica para cerrar, la ficha avanzada es esa presentación.
Se usan por separado según el producto. El strip de specs rápidas (P2) sirve en casi cualquier producto técnico. El timeline evolutivo (P4) solo si el producto tiene generaciones documentadas. El configurador de variantes (P5) solo si hay variantes reales que configurar. La traducción operativa de métricas (P6) solo si hay métricas normativas publicadas. El formulario WA (P8) solo si el lead cualificado aporta más que el botón WA directo. No uses un patrón que no resuelva un problema real del visitante — el scroll vano también cuesta.
Separando datos de template. Los arrays de datos (VARIANTES, TIMELINE, METRICAS, FAQ_ITEMS, MODELOS_RELACIONADOS, BLOG_RELACIONADO, SECTORES) van en el frontmatter del .astro o —mejor— en archivos de datos en src/data/ importados en la página. La plantilla HTML no cambia entre fichas del mismo sector; solo cambian los datos. En sitios grandes, crear un layout específico por sector (TechnicalProductLayout) que recibe los arrays como props y renderiza todos los patrones.
Sí — es puro frontend. El formulario recopila los campos con FormData, construye el mensaje como string con los datos relevantes y llama a window.open(wa.me/numero?text=...). Se abre WhatsApp con el mensaje pre-cargado en el dispositivo del visitante. Sin servidor, sin base de datos, sin terceros. La ventaja: cero costo de infraestructura, cero mantenimiento de backend. La limitación: no hay registro de leads — si necesitas CRM, complementa con un formulario secundario a una API o usa Cloudflare Pages Functions.
La voz y el ángulo. Un FAQ genérico: «¿Qué certificaciones tiene?» → «Cumple NFPA 1971-2018.» Un FAQ voz operador: «¿Por qué los grandes departamentos como FDNY o LAFD eligen el G-XTREME?» → respuesta de 200 palabras con tres razones concretas, verificables, que el jefe de cuerpo realmente busca antes de firmar. La diferencia no es el formato del acordeón: es entender las preguntas que el comprador real tiene pero no articula en el buscador. Eso se consigue hablando con los vendedores o con los compradores del sector — no inventando preguntas.
Solo si los datos son inexactos o atribuidos a competidores con nombre. La regla segura: compara datos que el propio fabricante publica (TPP, THL, certificaciones) y para los competidores usa solo datos de su literatura técnica pública. Si el competidor no publica sus datos, la tabla lo muestra como «no publicado» — ese dato en sí mismo es el argumento («somos el único que publica este número»). Evita afirmaciones comparativas de rendimiento sin fuente; mantén la comparación en datos objetivos verificables.
La pieza de la guía que viene antes, la que viene después y los módulos que arman la ficha.