Una tienda online con diseño y seguridad obsoletos arriesga reputación y ventas tras un incidente o una migración mal ejecutada. Quien gestiona una pyme necesita una ruta clara, medible y con garantías para actualizar la tienda sin sorpresas, con copias de seguridad y control de riesgos, lista para delegar al proveedor o ejecutar internamente.
Migrar a HTTPS sin sorpresas es posible: certificado SSL/TLS correcto, redirecciones 301 bien mapeadas, corrección de mixed content y actualización de Search Console y Analytics. Se incluye un plan paso a paso con checklist CSV para mapear redirecciones masivas, comandos y snippets reales (cURL, openssl, nginx/apache), guía de OCSP stapling y verificación masiva de mixed content, más comprobaciones post-migración y un plan de rollback para proteger tráfico, seguridad y SEO.
Resumen del proceso
Este resumen da la hoja de ruta clara y rápida. Cada paso es ejecutable y medible.
- Preparación y backups: clonar el sitio y exportar URLs al CSV.
- Certificado y cadena: instalar certificado, intermedios y comprobar OCSP stapling.
- Redirecciones 301: mapear cada URL en CSV y desplegar en staging.
- Contenido mixto: detectar y corregir recursos HTTP en masa.
- Pruebas y monitorización: Search Console, Analytics y alertas.
- HSTS y preload: solo tras semanas de pruebas; mantener rollback listo.
Paso 1: preparación y backups
La preparación evita la mayoría de problemas durante la migración. Hacer un backup completo antes de cualquier cambio es obligatorio.
Exportar y generar el CSV
Crear un CSV con todas las URLs antiguas y nuevas permite verificar redirecciones en masa.
Ejemplo de columnas mínimas para el CSV: old_url,new_url,status_expected,notes,last_checked
Código de ejemplo (primeras filas):
old_url,new_url,status_expected,notes,last_checked
http://midominio.com/,https:/midominio.com/,301,home,2026-05-20
http://midominio.com/producto-1,https:/midominio.com/producto-1,301,producto,2026-05-20
Infografía del flujo de migración
1. Backup y staging
2. Certificado y cadena
3. Redirecciones 301
4. Contenido mixto
5. Pruebas y monitorización
Validación inicial en staging
Probar cada redirección con curl evita sorpresas en producción.
Comando de verificación rápida: curl -I -L "https://midominio.com/ruta" devuelve los códigos y la cadena de redirecciones.
Paso 2: certificado y cadena
Elegir bien el certificado reduce fallos en navegadores y pasarelas de pago. La cadena de confianza y los intermedios son tan importantes como el certificado principal.
Comparativa práctica de tipos de certificados
| Tipo |
Coste |
Renovación |
Recomendado para |
| Let's Encrypt (DV) |
Gratis |
90 días |
Pequeñas tiendas y pruebas |
| DV pago |
Bajo |
1 año |
Sitios comerciales |
| OV |
Medio |
1 año |
Empresas y pagos |
| EV |
Alto |
1 año |
Confianza de marca |
| Wildcard / SAN |
Variable |
1 año |
Múltiples subdominios |
Instalación y cadena en servidores
En nginx usar fullchain para incluir intermedios. Un error común es subir solo el certificado del dominio.
Ejemplo nginx mínimo:
server {
listen 443 ssl http2;
server_name midominio.com;
ssl_certificate /etc/ssl/fullchain.pem;
ssl_certificate_key /etc/ssl/private.key;
ssl_trusted_certificate /etc/ssl/chain.pem;
}
Ejemplo Apache mínimo:
ServerName midominio.com
SSLEngine on
SSLCertificateFile /etc/ssl/fullchain.pem # contiene certificado + intermedios
SSLCertificateKeyFile /etc/ssl/private.key
Verificación con OpenSSL y herramientas
Comprobar la cadena: openssl s_client -connect midominio.com:443 -showcerts muestra los certificados y los intermedios.
Test externo recomendado: usar el comprobador de Let's Encrypt o SSL Labs para ver cadenas y puntuación.
OCSP stapling
Además de verificar OCSP stapling con openssl s_client -connect midominio.com:443 -status, es importante activarlo en el servidor y asegurar que el servidor entrega la respuesta OCSP correctamente usando la cadena de confianza adecuada. Ejemplo mínimo para nginx:
nginx
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/chain.pem; # cert chain (intermedios)
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;
Para Apache (mod_ssl) una configuración típica es:
apache
SSLUseStapling on
SSLStaplingCache shmcb:/var/run/ocsp(128000)
SSLCertificateFile /etc/ssl/fullchain.pem
SSLCertificateKeyFile /etc/ssl/private.key
Notas prácticas: el fichero ssl_trusted_certificate/SSLCertificateFile debe contener la cadena de intermedios que empata con la información OCSP del emisor; configurar un resolver público (Cloudflare/Google) y tiempos de timeout evita fallos en stapling cuando el servidor OCSP del emisor no responde. Tras activar, pruebe en lote con openssl s_client -connect midominio.com:443 -status y con SSL Labs para validar stapling, tiempos y la correcta inclusión de intermedios.
Paso 3: redirecciones y SEO
Mapear cada URL evita pérdida de posicionamiento. Un mapa en CSV permite comprobar automáticamente cada 301.
Cómo aplicar redirecciones masivas
Para Apache en .htaccess o VirtualHost usar reglas 301 específicas por URL o Rewriterule con mapa. Evitar redireccionar la raíz a páginas profundas.
Ejemplo Apache con RewriteMap (más eficiente para muchas URLs):
RewriteMap redirects txt:/etc/httpd/redirects.map
RewriteCond %{REQUEST_URI} ^/(.)
RewriteRule ^/(.)$ ${redirects:%{REQUEST_URI}|} [R=301,L]
Ejemplo nginx usando map y try_files para carga rápida en bloque grande.
Actualizar canonicals
Añadir la propiedad HTTPS en Google Search Console y subir el sitemap con URLs HTTPS.
Enviar sitemap recién generado y vigilar mensajes en Search Console durante 7 a 14 días.
Scripts para comprobar el CSV y 301s
Script corto en bash para validar CSV (simplificado):
while IFS=, read -r old new rest; do
code=$(curl -o /dev/null -s -w "%{http_code}" -I -L "$old")
echo "$old -> $new : $code"
done < redirects.csv
El error más frecuente en este punto es no actualizar enlaces internos y canonicals, lo que genera 404 y pérdida de ranking.
Actualizar search console
Tras desplegar HTTPS, siga un checklist concreto:
- Añadir la propiedad HTTPS en Google Search Console y enviar el sitemap con URLs HTTPS; usar la herramienta "Inspeccionar URL" para solicitar indexación de las páginas críticas (home, categorías, fichas de producto)
- En Google Analytics actualizar la URL por defecto de la propiedad (Universal Analytics) o revisar el Data Stream en GA4 para que recoja el dominio HTTPS; actualizar el
gtag('config', 'G-XXXXX') si usa gtag o publicar la versión actualizada del contenedor en Google Tag Manager
- Actualizar el archivo
robots.txt, la referencia al sitemap y las etiquetas canonical a las versiones HTTPS
- Revisar la configuración del CDN (certificados, reglas de redirección) y de las pasarelas de pago/webhooks para que acepten callbacks a HTTPS; probar transacciones en modo sandbox
- Reducir el TTL de DNS (por ejemplo a 300s) antes del cambio para poder revertir rápido si hace falta, y restaurarlo tras la estabilización
- Configurar alertas en Analytics y Search Console para 4xx/5xx y caídas de tráfico y vigilar las métricas clave 72 horas y 30 días tras la migración
Paso 4: contenido mixto y pruebas
El contenido mixto rompe páginas cuando el navegador bloquea recursos HTTP. Detectarlo y arreglarlo evita errores de interfaz.
Detección masiva de mixed content
Búsqueda simple: curl -sL https://midominio.com | grep -i 'http://' localiza recursos estáticos en HTML.
Uso avanzado: ejecutar Lighthouse en modo headless con Puppeteer para detectar recursos cargados por JavaScript.
Ejemplo básico con wget:
wget --recursive --no-parent --adjust-extension --span-hosts --convert-links https://midominio.com
grep -R "http://midominio.com" .
Correcciones concretas
Para WordPress actualizar URLs en la base de datos con SQL tras hacer backup.
SQL ejemplo:
UPDATE wp_posts SET post_content = REPLACE(post_content,'http://midominio.com','https:/midominio.com');
Si hay recursos de terceros, servirlos por CDN o contactar al proveedor para endpoints HTTPS.
Verificación post-arreglo
Volver a ejecutar los mismos checks y usar la pestaña de cobertura de Search Console para detectar 404/5xx.
Esto funciona bien en teoría, pero en la práctica el JS dinámico suele dejar recursos inseguros no visibles en HTML estático.
Mixed content dinámico
Cuando el contenido mixto proviene de JavaScript dinámico (APIs, lazy loading, widgets), los métodos estáticos (grep http://, wget) no alcanzan todo; conviene combinar pruebas headless y cambios seguros en el CMS. Primero, ejecute auditorías headless con Lighthouse/Puppeteer para capturar peticiones que no aparecen en HTML estático. Ejemplo rápido con WP‑CLI para WordPress (siempre con backup y --dry-run primero):
bash
wp search-replace 'http://midominio.com' 'https://midominio.com' --all-tables --recurse-objects --skip-columns=guid --dry-run
El flag --recurse-objects asegura que las cadenas en datos serializados se actualicen correctamente. Como mitigación temporal mientras corrige fuentes externas, puede servir el header HTTP Content-Security-Policy: upgrade-insecure-requests en el servidor para forzar a los navegadores a pedir recursos por HTTPS (usar con precaución y probar en staging). Para widgets de terceros, pida endpoints HTTPS al proveedor o cámbielos por versiones alojadas en CDN que soporten TLS.
Finalmente, automatice tests periódicos (Puppeteer + reportes) para detectar regresiones tras despliegues y confirmar que checkout y pasarelas de pago no quedan bloqueadas por contenido mixto.
Paso 5: HSTS, preload y rollback
HSTS aumenta la seguridad forzando HTTPS. Preload añade el dominio a navegadores, pero puede causar bloqueos permanentes si hay errores.
Primero enviar el header con max-age=60 en staging y vigilar 72 horas. Subir el valor progresivamente a semanas.
Progresión sugerida: 60s → 86400 (1 día) → 2592000 (30 días) → 31536000 (1 año) antes de solicitar preload.
Preloading y requisitos
Para solicitar preload se necesita HTTPS en todos los subdominios y un certificado válido que cubra los subdominios.
Si no se cumplen requisitos, el sitio podría quedar inaccesible para usuarios que ya cargaron la lista de preload.
Plan de rollback y emergencia
Si aparece un fallo grave, retirar el header HSTS y restaurar la configuración previa del proxy o CDN.
Mantener acceso administrativo por IP o VPN para acceder al servidor si los navegadores bloquean el sitio.
Errores que arruinan el resultado
Lista de fallos que suelen provocar pérdida de tráfico o rotura funcional.
Redirecciones incompletas
No mapear todas las URLs produce 404 y pérdida de ranking. Verificar cada URL crítica antes del deploy.
Ignorar mixed content
Dejar recursos por HTTP puede romper el checkout u opciones interactivas en navegadores modernos.
Activar HSTS/preload prematuramente
Solicitar preload sin pruebas puede bloquear el dominio y complica el rollback.
Cuándo no funciona este método / alternativas
La migración manual a HTTPS no aplica cuando la plataforma o el hosting ya gestionan HTTPS automáticamente (por ejemplo Shopify, Wix o un hosting con certificado gestionado). Tampoco es prioritaria para dominios de pruebas que no estén indexados. En esos casos, validar la configuración con el proveedor y documentar el comportamiento es suficiente.
Si el proveedor renueva y aplica certificados, la intervención técnica es mínima. Confirmar que el proveedor aplica redirecciones 301 y actualiza certificados intermedios.
Alternativas para sitios muy grandes
Para catálogos con cientos de miles de URLs usar proxy reverso o un rollout por secciones para minimizar impacto.
Síntesis y recomendación final
La migración a HTTPS protege datos y mejora la confianza de usuarios, y puede hacerse sin perder tráfico si se planifica. Mantener backups, CSV con redirecciones, verificación de la cadena y pruebas de contenido mixto reduce el riesgo.
Frase accionable: desplegar primero en staging, validar certificados e intermedios, luego promover a producción en ventana controlada y vigilar métricas durante 72 horas.
Un caso habitual: una tienda WooCommerce con 3.200 URLs que no mapearon todas las redirecciones perdió 18% de tráfico en dos semanas; tras corregir el CSV y restaurar canonicals recuperó el tráfico en 30 días.
Si se prefiere una revisión técnica puntual con el CSV y los scripts listados, se puede solicitar una comprobación externa que confirme la cadena, OCSP stapling y redirecciones.
Preguntas frecuentes
¿Qué hacer si el certificado HTTPS falla?
Comprobar la cadena de certificados y los intermedios con openssl. Restaurar un certificado válido temporalmente y vigilar logs.
Si openssl muestra errores de "unable to get local issuer certificate", falta un intermedio.
¿Cuál es la diferencia práctica entre HTTP y HTTPS?
HTTPS cifra datos entre el navegador y el servidor, lo que protege formularios y pagos. Google lo considera un factor de ranking desde hace años.
HTTPS también permite HTTP/2 y mejores tiempos de carga en muchos casos.
¿Cómo detectar mixed content en cientos de URLs?
Automatizar con scripts que descargan HTML y buscan 'http://' en recursos. Ejecutar Puppeteer para el JS dinámico.
Combinar checks con Search Console y pruebas manuales en páginas principales.
¿Cuánto cuesta migrar una web a HTTPS?
Coste orientativo: entre 0 y 400 EUR para certificados, más horas técnicas. Let's Encrypt supera los 200 millones de certificados activos, lo que reduce costes para pymes.
El coste real depende del soporte técnico y la complejidad del CMS.
¿Qué es OCSP stapling y por qué importa?
OCSP stapling permite que el servidor entregue la prueba de validez del certificado, reduciendo latencia y fallos. Verificar con openssl s_client -connect midominio.com:443 -status.
Si el stapling falla, algunos navegadores muestran advertencias y aumentan tiempos de carga.
¿Cuánto tiempo tarda en recuperar rankings tras la migración?
Si la migración está bien hecha, las señales de recuperación suelen aparecer entre 7 y 30 días. Vigilar Google Search Console y tráfico diario.
¿Qué métricas vigilar después de migrar?
Tráfico orgánico, posiciones en palabras clave principales y número de 4xx/5xx. Establecer alertas por subida de errores y caídas de tráfico.
Siguientes pasos y cierre
La lista mínima para ejecutar hoy: hacer backup, exportar URLs a CSV, instalar el certificado en staging, ejecutar el script de comprobación y revisar 10 páginas críticas.
La evidencia técnica disponible incluye comprobadores públicos y capturas de la cadena de certificados. La práctica habitual evita el preload hasta completar pruebas.
Datos para recordar:
- Google introdujo HTTPS como factor de ranking
- ENISA publicó guías sobre gestión de certificados
- Let's Encrypt superó los 200 millones de certificados activos
