Un npm run build que termina en verde da tranquilidad. También puede engañarte un poco.
El build confirma que el proyecto genera páginas. No confirma que el dominio correcto responde, que un formulario llega a destino, que el menú se puede recorrer con teclado o que Google encuentra la versión que quieres publicar. Son preguntas distintas y aparecen justo cuando da más pereza volver a abrir el proyecto.
Al principio publicaba con una revisión bastante difusa. Abría la home, comprobaba que no hubiera nada roto a simple vista y daba por hecho que el resto estaba bien. Al ampliar el portfolio, añadir versiones en dos idiomas, un sitemap generado y cabeceras propias, entendí que publicar no es un último clic. Es cambiar de tipo de problema.
Esta es la revisión que me ayuda a no pasar por alto lo básico. No pretende servir igual para una landing, una tienda o una aplicación con usuarios. Sirve para hacer las preguntas correctas antes de compartir una URL.
Empiezo por la página que alguien va a ver primero
No comienzo por Lighthouse ni por el código. Abro la URL final desde una ventana privada y recorro la web como si me la hubieran enviado por primera vez.
Miro si el mensaje principal se entiende sin contexto, si los enlaces llevan a páginas reales y si se ha quedado algún texto provisional. Reviso los botones, los datos de contacto, los títulos de las pestañas y las imágenes que aún podrían ser una versión de prueba. Cuando una página está a medias, suele delatarse rápido en ese recorrido.
Después intento encontrar una página importante sin usar la barra de direcciones. En un portfolio puede ser un proyecto; en una web de servicios, una página concreta; en un blog, un artículo reciente. Si solo llego porque conozco la estructura por dentro, la navegación necesita trabajo.
No es una comprobación sofisticada. Es de las que más evita publicar una web que técnicamente está terminada, pero deja a la persona que llega preguntándose qué hacer después.
Pruebo lo que no se ve hasta que falla
Los formularios merecen una prueba real en producción. No basta con que el navegador marque un campo obligatorio o con que aparezca un mensaje bonito al pulsar el botón.
Envío una prueba y compruebo que llega a quien tiene que llegar. También miro qué muestra la web mientras envía, qué ocurre si hay un error y si el usuario puede corregir un dato sin tener que empezar desde cero. Son situaciones poco espectaculares, pero una persona que quiere contactar contigo no debería descubrir que el formulario no funcionaba el día que lo necesitaba.
Aquí hay una comprobación rápida que no suelo saltarme. Navego por el formulario con Tab. Los campos deben tener una etiqueta clara, el foco debe verse y los errores tienen que decir qué necesita cambiar. Un campo que solo se explica con un placeholder puede parecer suficiente en una maqueta, pero no aguanta bien una interacción real. La guía de accesibilidad básica desarrolla esta parte con más detalle.
La validación del navegador ayuda a orientar. La que decide qué datos acepta una aplicación debe estar en el servidor. Por eso, antes de publicar un formulario, revisaría también qué datos pide y si hace falta pedirlos. En seguridad en formularios web explico el motivo sin convertir cada formulario en un problema de ciberseguridad.
Dejo el ratón a un lado un momento
Una navegación puede parecer impecable hasta que la pruebas sin ratón. En una ventana estrecha reviso que no aparezca scroll horizontal, que el menú no cubra el contenido y que los botones sigan siendo cómodos de pulsar. Después uso Tab para pasar por enlaces, botones y menús.
No busco hacer una auditoría completa en diez minutos. Busco detectar fallos claros. Un foco invisible, un orden extraño al tabular, un desplegable que no se puede cerrar o una acción que depende de pasar el cursor por encima son motivos para parar y revisar.
También compruebo encabezados y contenido. Una página puede usar letras grandes para todo y aun así no tener una jerarquía que ayude a leerla. Si una imagen contiene información, necesita una alternativa; si es decorativa, no debería generar ruido. Estas decisiones se toman mejor mientras todavía estás publicando que cuando ya hay veinte páginas siguiendo el mismo patrón.
Miro la web que recibe el navegador, no la que imaginé en Astro
En un proyecto estático hay una diferencia útil entre el código fuente y lo que termina publicado. Antes de lanzar cambios importantes, abro el HTML generado de una página principal y reviso el <head>.
En mi portfolio compruebo que título, descripción y canonical correspondan a la página. Como el sitio está en español e inglés, también reviso las relaciones hreflang y el sitemap. No tendría sentido que la estructura de rutas estuviera bien en el repositorio y una versión publicada señalara a una URL que no existe.
No hace falta añadir cada etiqueta posible. Importa que lo que haya sea coherente. Una página pública con noindex por accidente, una canonical que apunta a otra URL o un sitemap lleno de rutas que no quieres mostrar pueden crear problemas más difíciles de detectar que un enlace roto. El SEO técnico de mi portfolio y el artículo sobre hreflang explican las decisiones que hay detrás de esa revisión.
El sitemap ayuda a que Google descubra URLs. No obliga a Google a indexarlas ni a situarlas arriba en los resultados. Esa distinción evita publicar una página y esperar que el XML haga el resto.
Reviso cada petición que se lleva una visita
Antes de dar por buena una página, abro las herramientas del navegador y miro qué recursos está descargando. Es una costumbre que me ha ayudado más que obsesionarme con una puntuación.
Las imágenes suelen ofrecer la primera respuesta. Una portada enorme servida a un móvil, varias tipografías que apenas se usan o un script de terceros que ya no hace falta son costes que acompañan a cada visita. No siempre hay que quitarlos, pero debería haber una razón para mantenerlos.
También reviso los servicios externos. Analítica, mapas, vídeos, chat y píxeles de seguimiento afectan a rendimiento, privacidad y a veces a la política de seguridad del sitio. En mi configuración de despliegue, por ejemplo, la CSP tiene que permitir solo las conexiones y recursos que el portfolio utiliza de verdad. Copiar una política de otra web puede romper recursos; abrirla sin límites la vuelve poco útil. Eso es lo que intento explicar en cabeceras de seguridad web.
La privacidad entra en la misma conversación. Si una herramienta recoge datos antes de que alguien acepte hacerlo, una página de cookies no arregla el orden real de carga. Primero entiendo qué se ejecuta. Después decido si debe estar ahí y cómo se informa de ello.
Lo que dejo preparado para después
Hay comprobaciones que solo tienen sentido cuando la web ya recibe visitas. Durante los primeros días reviso rutas importantes, envíos de formulario y errores que pueda registrar la plataforma de despliegue.
Si tengo acceso a Search Console, envío el sitemap y consulto una o dos URLs prioritarias. No para forzar resultados inmediatos, sino para ver si Google puede acceder a la página como espero. Si una URL no se indexa, primero conviene separar descubrimiento, rastreo e indexación antes de cambiar cosas al azar.
La otra fuente de información es más sencilla. Preguntas repetidas, gente que no encuentra una página o enlaces que conducen a un sitio inesperado. Todo eso revela partes de la web que eran claras para quien la construyó y no tanto para quien la usa.
Publicar no termina la revisión
No aplico esta lista con la misma intensidad a todos los proyectos. Una landing sin formulario, analítica ni contenido dinámico no necesita el mismo recorrido que un sitio bilingüe con varias rutas. La clave es ajustar la revisión al riesgo, no añadir tareas porque queden bien en un documento.
Pero sí mantengo el orden. Primero, comprobar que lo que alguien verá funciona y se entiende. Después, revisar que la experiencia no excluye a quien navega de otra manera y que las señales técnicas coinciden con lo que quiero publicar. Por último, observar qué pasa cuando la web sale de mi ordenador.
Eso es lo que para mí convierte una publicación en una entrega cuidada. No una web perfecta. Una web en la que has comprobado lo suficiente como para no dejar los fallos más previsibles a la primera persona que llegue.