Publicar un sitio web no debería consistir en presionar un botón y esperar que todo funcione. Aunque el diseño se vea terminado, todavía pueden quedar enlaces incorrectos, formularios que no entregan mensajes, páginas bloqueadas para buscadores o componentes difíciles de usar desde un teléfono.
Una checklist de lanzamiento convierte esa revisión en un proceso repetible. No garantiza que nunca aparezca un problema, pero ayuda a encontrar los errores más importantes antes de que afecten a visitantes, consultas o medición.
Un sitio está listo para publicarse cuando sus recorridos importantes fueron probados, no cuando simplemente dejó de recibir cambios.
Definí qué significa estar listo
Antes de probar, acordá cuáles son los recorridos esenciales del sitio. Una web institucional puede necesitar que una persona comprenda la propuesta, encuentre un servicio y envíe una consulta. Otro proyecto puede incluir registro, descarga de documentos, búsqueda interna o acceso a un área privada.
Prepará una lista breve con:
- Las páginas y funciones que no pueden fallar.
- Los dispositivos y navegadores que se van a comprobar.
- Quién prueba cada área y quién corrige los problemas.
- Qué errores impiden publicar y cuáles pueden resolverse después.
- Una copia de respaldo y un procedimiento para volver a la versión anterior.
También conviene detener los cambios de contenido durante la revisión final. Si el equipo continúa modificando textos, enlaces y configuraciones mientras se prueba, los resultados dejan de representar la versión que será publicada.
Probá los recorridos como una persona visitante
Navegación, contenido y llamadas a la acción
Recorré el sitio sin usar el panel de administración ni accesos directos del equipo. Empezá desde la página principal, desde una página interna y desde una URL compartida en redes o campañas.
- Comprobá que el menú, el logotipo, el buscador y el pie de página lleven al destino esperado.
- Abrí botones, enlaces internos, documentos y vínculos externos.
- Buscá textos de prueba, fechas vencidas, imágenes temporales y páginas incompletas.
- Confirmá que teléfonos, correos y direcciones sean correctos.
- Revisá que cada llamada a la acción explique qué ocurrirá al utilizarla.
Formularios y confirmaciones
No alcanza con comprobar que el botón de envío responda. Completá cada formulario con datos válidos, campos vacíos, formatos incorrectos y mensajes extensos. Verificá qué ve la persona, qué recibe el equipo y dónde queda registrada la consulta.
La guía de formularios accesibles de W3C recomienda identificar los controles con etiquetas, ofrecer instrucciones y comunicar tanto los errores como la finalización correcta de una tarea. En la práctica, la prueba debería confirmar que:
- Los campos obligatorios se distinguen sin depender únicamente del color.
- Los errores indican qué corregir y conservan los datos que siguen siendo válidos.
- Existe una confirmación visible después del envío.
- La notificación llega al destinatario previsto y permite identificar su origen.
- Los controles pueden utilizarse con teclado.
Accesibilidad básica
Recorré las páginas usando Tab, Shift + Tab, Enter y las teclas de dirección. El foco debería ser visible, avanzar en un orden comprensible y alcanzar enlaces, botones y campos sin quedar atrapado. Las comprobaciones iniciales de accesibilidad de W3C también incluyen títulos de página, encabezados, alternativas de imágenes y revisión de errores en formularios. Son un punto de partida, no una auditoría completa.
Revisá móviles, rendimiento y compatibilidad
Una ventana reducida en una computadora no reemplaza una prueba en dispositivos reales. Cuando sea posible, utilizá al menos un teléfono y una computadora, y combiná pantallas táctiles con navegación mediante teclado y mouse.
- Verificá que no exista desplazamiento horizontal involuntario.
- Comprobá menús, modales, carruseles, videos y elementos fijos.
- Revisá que botones y enlaces puedan tocarse sin activar otro control.
- Probá orientaciones vertical y horizontal cuando resulten relevantes.
- Observá el sitio con una conexión lenta y sin datos almacenados en caché.
Medí una selección representativa de páginas, no solo la portada. La documentación de Web Vitals diferencia las mediciones de laboratorio, útiles antes de publicar, de los datos de campo producidos por visitas reales. Por eso una buena puntuación previa es una referencia, pero el rendimiento debe seguir observándose después del lanzamiento.
Controlá HTML, URL e indexación
Errores de marcado y enlaces
Las herramientas automáticas ayudan a encontrar etiquetas mal cerradas, atributos duplicados y otras inconsistencias. El validador de marcado de W3C sirve para comprobar la validez del documento, pero W3C aclara que esa validación no equivale a una evaluación completa de calidad. Un HTML válido todavía puede contener textos incorrectos, recorridos confusos o funciones rotas.
Si una página cambió de dirección, evitá dejar la URL anterior sin respuesta. Las redirecciones HTTP documentadas por MDN permiten enviar a visitantes y sistemas hacia el nuevo destino. Probá cada redirección y descartá cadenas, bucles o destinos irrelevantes.
Visibilidad en buscadores
Un error frecuente es trasladar al sitio público una configuración usada para ocultar el entorno de pruebas. Revisá robots.txt, etiquetas robots, URL canónicas y mapas del sitio. Google documenta que la directiva noindex impide que una página aparezca en los resultados; por eso debe utilizarse deliberadamente y no quedar activa por descuido.
Después de publicar, utilizá la herramienta de inspección de URL de Search Console para probar páginas prioritarias, revisar si pueden indexarse y comparar la versión en vivo con la información que Google ya conoce.
Qué controlar después del lanzamiento
La publicación no termina la prueba: habilita la primera revisión en condiciones reales. Durante las horas y días siguientes, controlá:
- Disponibilidad del sitio y errores del servidor.
- Recepción de formularios, correos y otras conversiones.
- Páginas no encontradas y redirecciones utilizadas.
- Eventos de analítica y exclusión del tráfico interno.
- Rendimiento de páginas críticas.
- Problemas de rastreo, indexación o seguridad informados por las herramientas conectadas.
Registrá cada incidente con URL, dispositivo, pasos para reproducirlo, resultado esperado y evidencia. Descripciones como “el formulario no funciona” generan más demora que un caso reproducible.
Una checklist breve para decidir la publicación
- Confirmá que existe una copia recuperable.
- Probá los recorridos esenciales de principio a fin.
- Enviá todos los formularios y verificá su recepción.
- Revisá navegación por teclado y foco visible.
- Probá páginas representativas en móvil y escritorio.
- Controlá enlaces, redirecciones y respuestas de error.
- Verificá configuraciones de indexación y medición.
- Asigná responsables para la observación posterior.
No todos los hallazgos tienen la misma gravedad. Priorizá primero lo que impide acceder, comprender, consultar o completar una acción; luego corregí problemas de presentación y mejoras menores.
Si necesitás planificar, desarrollar y probar el proyecto como un proceso integrado, podés conocer los servicios de sitios web de Ideasweb. La decisión de publicar debería basarse en evidencia concreta: recorridos probados, errores críticos resueltos y un equipo preparado para observar lo que suceda después.
