Publicar un sitio estático no termina cuando aparece el enlace. La pregunta importante llega después: ¿alguien lo abrió?
También importa de dónde llegó la visita, qué página se abrió primero, si el sitio se está viendo en móvil o escritorio, qué países aparecen en el tráfico y si las imágenes, PDFs o archivos pesados ya están consumiendo demasiado ancho de banda.
Para esa primera lectura no siempre hace falta instalar una suite completa de medición. Muchas veces basta con estadísticas claras, conectadas al proyecto que acabas de publicar.
Empieza por la pregunta que debe responder el sitio
Las estadísticas se vuelven confusas cuando todas las cifras parecen igual de importantes.
Un sitio estático suele tener un objetivo concreto. Puede ser un portafolio, un CV en línea, una landing page, una vista previa para cliente, documentación, un proyecto escolar, una página generada con IA o un PDF publicado como enlace. Cada caso pide una lectura distinta.
| Tipo de sitio | Primera pregunta | Datos que conviene mirar |
|---|---|---|
| Portafolio | ¿El enlace llegó a clientes o reclutadores? | Visitantes, fuentes, páginas principales, dispositivos |
| Landing page | ¿Qué canal generó visitas? | Fuentes, UTM, páginas principales, países |
| CV en línea | ¿Se puede revisar bien desde móvil? | Dispositivos, navegadores, páginas vistas |
| Vista previa para cliente | ¿La versión correcta fue abierta? | Visitas recientes, países, dispositivos, páginas |
| Documentación | ¿Los usuarios llegaron a la página correcta? | Páginas principales, fuentes, rutas raras |
| Sitio con imágenes o PDF | ¿El peso del contenido ya se nota? | Ancho de banda, páginas principales, tamaño de archivos |
Si no sabes qué debe probar el sitio, el panel no puede decidir por ti. Verás una línea subir o bajar, pero no sabrás si toca cambiar el texto, revisar una ruta, compartir mejor el enlace o conectar un dominio.
Visitas y visitantes no son lo mismo
Las visitas o páginas vistas muestran cuántas veces se cargó una página. Los visitantes dan una idea más cercana de cuántas personas, navegadores o sesiones distintas llegaron al sitio.
Ambas cifras sirven, pero no cuentan la misma historia.
Durante los primeros días, tú, tu equipo, un cliente o un profesor pueden abrir y recargar el mismo enlace muchas veces. Eso sube las páginas vistas sin aumentar realmente la audiencia. También puede pasar lo contrario: pocas visitas, pero desde varias fuentes y dispositivos distintos. Para un portafolio, CV o prototipo, esa señal puede ser suficiente para tomar decisiones.
| Indicador | Sirve para | Error común |
|---|---|---|
| Páginas vistas | Actividad por URL | Confundir pruebas internas con demanda real |
| Visitantes | Alcance aproximado | Leerlo como número exacto de personas |
| Páginas principales | URLs que sí se abrieron | Mirar solo la página de inicio |
| Ancho de banda | Peso de archivos y presión sobre el plan | Descubrir demasiado tarde que una página es pesada |
Cada herramienta usa nombres diferentes. Google Analytics 4 trabaja con eventos, y page_view es uno de los eventos que se envían cuando una página se carga. Herramientas más ligeras como Plausible o Cloudflare Web Analytics suelen mostrar páginas vistas, visitantes, fuentes, países, dispositivos y navegadores de forma más directa.
Lo importante no es el nombre exacto. Es leer los datos juntos. Páginas vistas, visitantes, fuentes y páginas principales explican mejor qué pasó que una sola cifra aislada.
En DeployPages, las estadísticas de proyecto muestran páginas vistas, visitantes estimados, ancho de banda, páginas principales, referentes, países, dispositivos, navegadores, sistemas operativos y visitas recientes. Para un sitio estático recién publicado, esa primera capa suele ser suficiente.
Las fuentes muestran si el enlace se distribuyó bien
Muchos lanzamientos pequeños no fallan por el sitio. Fallan porque nadie vio el enlace, o porque se compartió en el lugar equivocado.
Las fuentes de tráfico ayudan a separar esos casos.
| Lo que ves | Qué puede significar | Siguiente paso |
|---|---|---|
| Mucho direct | Correo, chat, QR, enlace copiado o referente ausente | Usar UTM la próxima vez que compartas |
| Una red social domina | La publicación o un repost funcionó | Revisar páginas y dispositivos de ese tráfico |
| Empieza a aparecer búsqueda | La página se está encontrando fuera del primer envío | Revisar title, description y dominio |
| Dominios internos o de cliente | Hay tráfico de revisión | No mezclarlo con respuesta pública |
| Referentes extraños | Ruido, bots o visitas poco útiles | No cambiar el sitio por esa señal |
Si vas a compartir la misma página por correo electrónico, WhatsApp, Instagram, LinkedIn, un QR o un link in bio, prepara las URLs con nombres claros. El generador UTM permite definir source, medium y campaign antes de publicar.
No se trata de tener atribución perfecta. Se trata de evitar la pregunta de siempre: "¿de dónde venía este enlace?".
Dispositivos y navegadores te dicen dónde probar
Un sitio estático suele construirse en una computadora y abrirse en un teléfono.
Un portafolio que se ve ordenado en escritorio puede volverse una lista muy larga en móvil. Una landing page puede mostrar el botón principal arriba en una pantalla grande y esconderlo demasiado abajo en un teléfono. Un CV en HTML puede verse bien en Chrome de escritorio y sentirse apretado en Safari móvil.
Los datos de dispositivo, navegador y sistema operativo no deciden el diseño por ti. Te dicen dónde probar primero.
Si la mayoría de visitas viene de móvil, abre el enlace real en un teléfono antes de reescribir toda la página. Si aparece mucho iOS Safari, revisa imágenes, videos, tamaños de fuente y áreas táctiles ahí. Si una revisión de cliente viene de un navegador viejo, evita que la conversación se convierta en un problema de compatibilidad.
Esta información es más útil que repetir "mobile first" sin contexto. Habla del sitio que acabas de publicar.
Las páginas principales rompen suposiciones
Quien publica un sitio suele pensar en una entrada principal. Los visitantes pueden usar otra.
Alguien comparte una URL interna. Un QR apunta a una ruta de campaña. Un documento viejo conserva un enlace anterior. Una búsqueda encuentra primero un artículo. Un sitio generado con IA puede dejar visible una ruta de prueba que nadie revisó.
Mira las páginas principales especialmente después de:
- subir una nueva versión;
- pasar de un enlace de vista previa a un dominio personalizado;
- migrar desde GitHub Pages, un portafolio viejo o una documentación;
- usar varios enlaces para campaña, correo, redes o QR;
- cambiar
index.html, navegación o rutas de archivos; - publicar PDFs, imágenes o descargas.
Que una página interna sea la más vista no siempre es malo. Tal vez es mejor entrada que el inicio. Lo preocupante es que arriba aparezcan rutas viejas, descargas rotas o páginas que todavía no estaban listas para compartirse.
El ancho de banda aparece tarde si no lo miras
El ancho de banda no se siente tan emocionante como las visitas, pero en sitios estáticos puede ser la señal más práctica de costo y rendimiento.
Imágenes grandes, PDFs, videos de fondo, tipografías pesadas y capturas exportadas sin compresión no se notan cuando solo abren el enlace tres personas. Se notan cuando el sitio entra en una campaña, un portafolio, un QR impreso o una publicación que empieza a circular.
Conviene mirar ancho de banda si:
- el sitio usa muchas fotos, capturas o imágenes de producto;
- compartes PDFs, menús, presentaciones o archivos desde el mismo sitio;
- una campaña puede generar un pico corto;
- el proyecto se acerca a los límites del plan;
- la audiencia entra sobre todo desde móvil.
El ancho de banda no te dice automáticamente qué archivo pesa demasiado. Funciona como alerta. Después toca revisar dimensiones de imágenes, compresión, lazy loading, videos, fuentes y dónde se colocan los archivos grandes.
Estadísticas integradas primero, medición avanzada después
Google Analytics, Plausible, Matomo, Fathom, Simple Analytics o PostHog pueden ser buenas opciones. La pregunta es cuándo agregarlas.
Al publicar un sitio estático, las primeras dudas suelen ser más simples:
- ¿El enlace abre?
- ¿De dónde vienen las visitas?
- ¿Qué páginas se abren?
- ¿La gente entra desde móvil o escritorio?
- ¿Los países coinciden con lo esperado?
- ¿El ancho de banda se mantiene razonable?
Las estadísticas integradas funcionan bien para esa primera capa porque están ligadas al proyecto publicado. Subes una carpeta, recibes un enlace HTTPS, lo compartes y lees la reacción inicial sin modificar los archivos estáticos para meter otro script.
Una herramienta de medición más completa tiene sentido cuando necesitas clics de botones, embudos, conversiones, pruebas A/B, campañas pagadas, usuarios con sesión, eventos de producto o datos de e-commerce.
Mantener separados esos niveles ayuda. Las estadísticas de publicación responden si el sitio se está viendo. La analítica de producto responde qué hacen las personas después de llegar.
Privacidad, cookies y scripts externos
En América Latina no hay una sola regla idéntica para todos los países, pero la expectativa básica es clara: si agregas herramientas de medición, debes entender qué datos recogen y explicarlo donde corresponda.
Una estadística de lanzamiento no es lo mismo que una pila completa de tracking.
| Nivel | Pregunta principal | Ejemplos |
|---|---|---|
| Estadísticas de publicación | ¿El enlace público fue abierto? | Páginas vistas, fuentes, dispositivos, países, ancho de banda |
| Analítica de marketing o producto | ¿Qué hizo la persona dentro del sitio? | Eventos, conversiones, segmentos, pruebas A/B, publicidad |
DeployPages ofrece la primera lectura ligada al proyecto. Eso no reemplaza revisar tu política de privacidad. Si agregas Google Analytics, píxeles de anuncios, mapas de calor, chat, formularios externos u otros scripts, revisa qué se envía, qué se guarda en el navegador y qué aviso necesita tu sitio.
La idea no es asustar a quien publica una página pequeña. Es evitar que un sitio simple termine cargando herramientas que nadie configuró ni explicó.
Una rutina simple para la primera semana
No necesitas mirar estadísticas todo el día. Para un sitio estático, unas pocas revisiones suelen bastar.
| Momento | Qué mirar | Por qué |
|---|---|---|
| Primera hora | Si la página abre, 404, rutas de imágenes o scripts | Corregir antes de compartir más |
| Primer día | Fuentes, dispositivos, páginas principales | Ver si la distribución y el diseño coinciden con la audiencia |
| Primera semana | Tendencia, países, ancho de banda, páginas que siguen activas | Decidir si mejorar, mantener o reemplazar |
| Después de una nueva versión | Páginas principales y visitas recientes | Confirmar que no rompiste una URL útil |
| Después de conectar dominio | Direct, búsqueda, URLs anteriores | Ver si el dominio reemplazó al enlace de prueba |
La meta no es hacer reportes por costumbre. La meta es saber qué hacer: arreglar una ruta, comprimir una imagen, cambiar el enlace compartido, conectar un dominio o pasar a una medición más profunda.
Cómo encaja DeployPages
DeployPages trata las estadísticas como parte del flujo de publicación.
Puedes publicar una carpeta estática, un ZIP, un build front-end, un sitio generado con IA, una página con PDF o un portafolio, y luego revisar en el proyecto páginas vistas, visitantes estimados, fuentes, páginas principales, países, dispositivos, navegadores, sistemas, ancho de banda y visitas recientes.
Ese mismo proyecto puede crecer hacia dominio personalizado, protección con contraseña, restaurar una versión anterior, publicación por CLI y estadísticas.
Para muchos sitios estáticos, ese orden es más natural: publicar primero, mirar señales reales, y después decidir si el proyecto merece dominio, más optimización o una herramienta de analítica más profunda.