≡En resumen
- El website development termina en un lanzamiento que conviene tratar como un proyecto con su propio checklist.
- Todo se prueba antes en un entorno de staging idéntico a producción y bloqueado a buscadores.
- Si cambian las URL, cada dirección antigua necesita una redirección 301 a su equivalente nueva.
- Analítica, consentimiento de cookies y textos legales deben funcionar desde el primer minuto, no semanas después.
- Tras publicar hay que retirar el bloqueo de indexación, enviar el sitemap y vigilar errores durante varias semanas.
01 ¿Qué es el website development?
Website development es la forma inglesa de referirse al desarrollo de una web concreta. Las fases completas de un proyecto, las metodologías y quién puede desarrollarlo las tratamos en la ficha de fases del web development. Esta ficha se centra en el tramo final, el que más problemas da y menos se documenta: el paso de una web terminada en pruebas a una web publicada que funciona, se mide y se posiciona.
02 Entorno de staging: dónde se prueba antes de lanzar
El staging (entorno de preproducción) es una copia de la web en un servidor o subdominio aparte, lo más parecida posible a producción: misma versión de PHP o Node.js, misma base de datos, mismas integraciones en modo de pruebas. Es donde el cliente revisa y donde se ensaya el lanzamiento.
- ✓Misma configuración de servidor que producción: versión del lenguaje, extensiones, caché y HTTPS.
- ✓Acceso restringido con contraseña o por IP, para que nadie ajeno lo vea.
- ✓Bloqueo a buscadores con la etiqueta noindex o la cabecera X-Robots-Tag, además de la contraseña.
- ✓Pasarelas de pago, correo y CRM en modo de pruebas, para no cobrar ni enviar mensajes reales.
- ✓Datos personales reales sustituidos por datos ficticios siempre que sea posible.
03 Pruebas de calidad (QA) antes de publicar
| Área | Qué comprobar | Cómo |
|---|---|---|
| Funcional | Formularios, reservas, pagos, buscador, área privada | Recorridos completos con datos de prueba y revisión del correo o CRM de destino |
| Dispositivos | Móvil, tableta y escritorio en los navegadores principales | Dispositivos reales o herramientas de emulación |
| Contenido | Textos finales, precios, enlaces rotos, imágenes con texto alternativo | Rastreo completo del staging con una herramienta SEO |
| Rendimiento | Core Web Vitals y peso de las páginas principales | Pruebas de laboratorio sobre las plantillas clave |
| Accesibilidad | Navegación con teclado, contraste, etiquetas de formularios | Revisión manual y validadores automáticos |
| Seguridad | Modo depuración desactivado, contraseñas por defecto, dependencias | Revisión de configuración y de actualizaciones pendientes |
04 Redirecciones: no perder el tráfico de la web anterior
Si la nueva web sustituye a otra y cambian las direcciones, cada URL antigua con visitas o enlaces debe llevar a su equivalente nueva con una redirección 301. Google recomienda redirecciones permanentes del lado del servidor, evitar cadenas y mantenerlas al menos un año.
-
1
Extrae todas las URL antiguas
Del sitemap, de un rastreo completo, de la analítica y de los enlaces externos que recibe la web.
-
2
Crea el mapa de redirecciones
Una hoja con URL antigua y URL nueva, siempre hacia la página más parecida, no todo a la portada.
-
3
Incluye imágenes y PDF
Los archivos enlazados desde fuera también reciben visitas y deben redirigirse si cambian de ruta.
-
4
Prueba en staging
Verifica que cada redirección responde con 301 y llega al destino final en un solo salto.
-
5
Revisa tras publicar
Vigila los errores 404 en el servidor y en Search Console durante las primeras semanas.
05 Analítica, consentimiento y textos legales
La analítica que no se configura antes del lanzamiento no se puede recuperar después: los datos de los primeros días, que son los que muestran si la nueva web funciona mejor que la anterior, se pierden. Tienes el proceso completo en nuestra guía para configurar Google Analytics 4 con eventos y conversiones.
- ✓Etiqueta de analítica instalada en todas las plantillas y conversiones clave definidas como eventos.
- ✓Gestor de consentimiento que bloquea cookies no necesarias hasta que el usuario acepta (art. 22.2 de la LSSI).
- ✓Píxeles publicitarios condicionados al consentimiento.
- ✓Aviso legal con los datos del titular (art. 10 de la LSSI) y política de privacidad según el RGPD.
- ✓Política de cookies que describe las cookies reales tras el lanzamiento.
- ✓Formularios con información de privacidad y casilla de aceptación cuando corresponda.
06 El día del lanzamiento: orden de operaciones
-
1
Copia de seguridad completa
De la web antigua y de la nueva, archivos y base de datos, guardada fuera del servidor.
-
2
Congela los cambios
Nadie edita contenido ni publica pedidos en la web antigua durante la ventana de migración.
-
3
Publica y activa redirecciones
Despliega la versión final, activa el mapa de redirecciones y comprueba el certificado HTTPS.
-
4
Retira los bloqueos
Quita el noindex y las reglas de robots.txt del staging, y la contraseña de acceso.
-
5
Prueba de humo
Recorre portada, servicios, formulario, pago y área privada en producción real.
-
6
Avisa a Google
Envía el sitemap XML en Search Console y usa la herramienta de cambio de dirección solo si cambias de dominio.
07 Errores frecuentes al lanzar una web
| Error | Síntoma | Cómo evitarlo |
|---|---|---|
| Noindex del staging en producción | Las páginas desaparecen de Google en días | Revisar meta robots y cabeceras justo después de publicar |
| Redirigir todo a la portada | Google puede tratarlas como soft 404 y se pierde el tráfico de esas páginas | Mapa de redirecciones página a página |
| Formularios que no llegan | Cero contactos la primera semana | Probar el envío real a cada destinatario y revisar la carpeta de spam |
| Analítica duplicada o ausente | Visitas que se duplican o no aparecen | Una sola etiqueta por plantilla, verificada con la vista en tiempo real |
| Contenido mixto HTTP/HTTPS | Candado roto o recursos bloqueados | Buscar y sustituir URL absolutas con http antes de publicar |
| Correo del dominio caído | No llegan emails tras cambiar DNS | Copiar los registros MX, SPF y DKIM antes de tocar el DNS |
Casi todos estos fallos tienen algo en común: no son errores de programación, sino tareas de cierre que nadie tenía asignadas. Por eso un checklist de lanzamiento con responsable por cada punto evita más problemas que cualquier herramienta.
08 Después del lanzamiento: las primeras semanas
Google indica que en una web mediana pueden pasar varias semanas o más hasta que muestre las nuevas URL en lugar de las antiguas. Los informes de indexación y de páginas de Google Search Console son tu mejor termómetro. Durante ese tiempo es normal ver fluctuaciones; lo que no es normal es un aumento sostenido de errores o una caída de páginas indexadas.
Primeras 24 horas
Errores del servidor, formularios y pagos reales, certificados y correos de notificación.
Primera semana
Errores 404, cobertura de indexación, conversiones en la analítica y velocidad con datos reales.
Primer mes
Comparación de tráfico orgánico y conversiones con el mismo periodo de la web anterior.
En adelante
Actualizaciones de seguridad, copias y revisión de contenidos dentro de un plan de mantenimiento.
El lanzamiento no es el final: sin un plan de mantenimiento web, la web acumula versiones sin parches en pocos meses. Si tu proyecto incluye integraciones o lógica propia, una agencia de desarrollo web puede encargarse del despliegue y del seguimiento; si es una web corporativa, el equipo de diseño y desarrollo web puede asumir todo el proceso.
Preguntas frecuentes sobre Website Development
Significa desarrollo de un sitio web: la construcción técnica de una web concreta, desde la programación y las integraciones hasta las pruebas y la publicación en un servidor.
Es una copia de la web en un servidor o subdominio aparte, protegida y bloqueada a buscadores, donde se prueban los cambios antes de publicarlos en la web real.
Formularios y pagos, visualización en móvil y escritorio, enlaces rotos, velocidad, accesibilidad, seguridad, redirecciones de las URL antiguas, analítica, consentimiento de cookies y textos legales.
Redirigiendo con 301 cada URL antigua a su equivalente, retirando el bloqueo de indexación del staging, enviando el sitemap nuevo en Search Console y vigilando errores las primeras semanas.
Google recomienda mantenerlas el mayor tiempo posible y, en general, al menos un año. Si tienen enlaces externos, lo prudente es no retirarlas nunca.
Un día laborable de poco tráfico y con el equipo disponible las horas siguientes. Evita viernes por la tarde y vísperas de festivos.
Una fluctuación temporal es normal mientras Google procesa las nuevas URL. Una caída fuerte y sostenida suele indicar redirecciones que faltan, páginas bloqueadas o contenido eliminado.
Fuentes consultadas
Sobre el autor
Germán Gutiérrez
Development Manager en appyweb
Dirige el equipo de desarrollo de appyweb: aplicaciones web y móviles, SaaS, integraciones y arquitectura de software.
Ver perfil en LinkedIn ↗