Cómo verifiqué, afirmación por afirmación, que un proyecto era exactamente lo que decía ser: el caso Inflables Publicitarios
Después de encontrar varios problemas reales en esta serie, ¿cómo se ve un proyecto donde la documentación sí coincide con la producción?
Por Pietro Fiorillo ·
Índice del artículo
Por qué termino esta serie con un caso que confirma lo documentado
A lo largo de esta serie encontré páginas publicadas que describían funcionalidades inexistentes, prerenderizado que dejó de funcionar y hasta un HTML con contenido cruzado entre páginas. Si solo mostrara esos casos, estaría dando una imagen sesgada de mi propio trabajo. Este cierre verifica, con el mismo método, un proyecto donde la documentación sí se sostiene.
La afirmación 1: un export estático real de Next.js
El HTML público incluye rutas /_next/ y el patrón de carga de JavaScript propio de un export estático de Next.js. No hay señales de un servidor dinámico detrás.
La afirmación 2: datos estructurados reales, con un hueco concreto
El sitio sirve un bloque <script type="application/ld+json"> real, con Organization y WebSite conectados, teléfono y área de servicio incluidos.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"name": "Inflables Publicitarios",
"areaServed": "Argentina",
"telephone": "+549...",
"sameAs": []
},
{
"@type": "WebSite",
"name": "Inflables Publicitarios",
"inLanguage": "es-AR"
}
]
}El campo sameAs, pensado para enlazar perfiles de redes sociales u otros directorios donde aparece la misma entidad, está vacío. No es un error que rompa nada, pero es una oportunidad real de reforzar la entidad que no está aprovechada.
La afirmación 3: un CTA de WhatsApp distinto por línea de producto
Cada línea de producto arma un link de WhatsApp con un mensaje ya escrito, específico de esa línea.
https://wa.me/549.../?text=Hola%2C%20quiero%20consultar%20por%3A%20Stands%20inflables.La afirmación 4: una sola página, navegada por anclas
La navegación del sitio usa enlaces internos (#nosotros, #productos) en vez de rutas distintas, consistente con una landing de una sola página pensada para llevar al visitante del catálogo a WhatsApp en pocos clics.
Resultados medibles
| Métrica | Resultado | Entorno / evidencia |
|---|---|---|
| Lighthouse Performance (móvil, lab) | 90 / 100 | Lighthouse 13.5.0, throttling simulado |
| LCP (lab) | 3,6 s | Misma medición Lighthouse, no es un dato de campo (CrUX) |
| URLs en el sitemap | 1 | Consistente con un sitio de una sola página |
| Afirmaciones documentadas verificadas | 4 de 4 | Export estático, JSON-LD, WhatsApp por producto, navegación por anclas |
Una auditoría que solo encuentra problemas no es más rigurosa, es solo incompleta en la otra dirección.
Mi participación en este proyecto
Mi participación en Inflables Publicitarios incluyó el desarrollo del sitio y el SEO técnico, como parte de mi trabajo en MANYA Digital.
Lo que haría distinto: un campo vacío que es fácil de completar
El único pendiente real que encontré es el campo sameAs vacío en el JSON-LD. Es una mejora de bajo esfuerzo y sin riesgo: agregar los perfiles sociales reales de la empresa, si existen, fortalece la entidad sin tocar nada más del sitio.
Qué probaría después
Completaría el campo sameAs con los perfiles reales de la empresa y evaluaría si agregar datos estructurados Product por línea de fábrica (en vez de solo Organization y WebSite a nivel de sitio) ayuda a que cada producto se entienda mejor en buscadores y motores de IA.
Fuentes
Preguntas frecuentes
¿Por qué el sitio es una sola página en vez de varias?
Porque el objetivo es que el visitante llegue del catálogo a WhatsApp en dos clics. Para una fábrica con 10 líneas de producto y un proceso de venta que se resuelve por consulta directa, una landing con navegación por anclas reduce la fricción mejor que una arquitectura de muchas páginas.
¿Qué significa que el campo sameAs esté vacío?
Que el dato estructurado Organization no enlaza ningún perfil de redes sociales o directorio externo. No rompe nada, pero es una oportunidad perdida de conectar la entidad con otras menciones de la marca en la web.
¿Cómo verificaste esto sin acceso al repositorio?
Pedí el HTML público con curl y leí directamente el bloque JSON-LD, los links de WhatsApp y las rutas de Next.js que aparecen en el código fuente servido. No necesité el repositorio para confirmar que cada afirmación documentada es real.
¿Por qué cada botón de WhatsApp tiene un mensaje distinto precargado?
Porque arma automáticamente un mensaje específico por producto («quiero consultar por: Stands inflables»), así el equipo de ventas sabe de entrada qué le interesa a la persona sin que tenga que escribirlo.
¿El sitio es realmente estático?
Sí. El HTML público incluye rutas /_next/ típicas de un export estático de Next.js, consistente con lo documentado: generación en build, sin servidor Node en producción.
¿Cuánto cuesta mantener un sitio así?
Es de los más económicos de mantener de toda esta serie: una sola página estática, sin CMS, sin base de datos y sin backend propio. El costo real es el tiempo de actualizar fotos y el catálogo cuando cambia.