Idiomas

Migración de HTTP a HTTPS

El manual paso a paso para migrar de HTTP a HTTPS: auditoría previa a la migración, elección del certificado, pruebas en staging, mapeo de redirecciones a escala, actualización de las URL preferidas, sitemaps y hreflang, cómo configurar bien la cobertura en Search Console, ventanas de monitorización, regresiones del día del lanzamiento y un plan de reversión.

Publicado por primera vez: 3 jul 2026 · Última actualización: 21 ago 2026 · Avanzado
Idiomas
AIEscrito porAI v2
1 señal de evidencia en esta página

Una migración de HTTP a HTTPS es una migración web solo de protocolo: mismo host, rutas, cadenas de consulta, contenido y plataforma; solo el esquema pasa de http:// a https://. Como nada más cambia, las 301 cargan con todo el peso (las 301 no pierden PageRank) y no hace falta la Change of Address tool. El orden que conserva el tráfico: mida la línea base del sitio HTTP en producción, elija e instale un certificado TLS (un certificado DV gratuito obtiene la misma señal ligera de posicionamiento que cualquiera de pago; Google comprueba el esquema, no la entidad emisora), ensaye todo el proceso en staging y después haga el cambio: redirija con 301 cada URL una a una del lado del servidor, marque cada URL HTTPS como su propia versión preferida, reapunte cada enlace interno, sitemap y hreflang, y corrija el contenido mixto bloqueable antes de que rompa sus scripts el día del lanzamiento. Después, añada una Domain property en Search Console (cubre automáticamente todas las variantes de protocolo y host) o verifique las propiedades HTTPS individualmente si quiere datos segmentados, envíe el sitemap HTTPS, conserve las redirecciones al menos un año y monitorice Crawl Stats y la indexación para distinguir una caída que se mantiene (rotura) de una caída que se recupera (asentamiento). Tenga un plan de reversión, pero repare HTTPS primero, porque la caché, las cookies y los service workers pueden hacer que una reversión real a HTTP sea insegura, y trate la preload de HSTS como algo lento y arriesgado de revertir, no como una puerta de un solo sentido.

TL;DR — Pasar de HTTP a HTTPS es una migración web solo de protocolo: mismo host, rutas, cadenas de consulta, contenido y plataforma; solo cambia el esquema. Eso la convierte en la migración de menor riesgo que existe si todo eso se mantiene, pero la disciplina es idéntica a la de cualquier mudanza de sitio. Mida la línea base del sitio HTTP en producción, elija e instale un certificado TLS (un certificado DV gratuito obtiene la misma señal ligera de posicionamiento que cualquiera de pago; Google comprueba el esquema, no la entidad emisora), ensaye en staging y después haga el cambio: redirija con 301 cada URL una a una y del lado del servidor (las 301 no pierden PageRank), haga que cada página HTTPS se declare como su propia URL preferida, reapunte cada enlace interno, cada entrada de sitemap y cada anotación hreflang, y elimine el contenido mixto bloqueable antes de que rompa sus scripts. Añada una Domain property en Search Console (cubre de una vez todas las variantes de esquema y host) o verifique las propiedades HTTPS individualmente si quiere datos segmentados, envíe el sitemap HTTPS y no toque la Change of Address tool: es para mudanzas de dominio. Conserve las redirecciones al menos un año (es un mínimo, no una fecha de caducidad). Monitorice Crawl Stats y la indexación: una caída que se recupera es el movimiento asentándose; una caída que se mantiene significa que algo se rompió. Tenga un plan de reversión, pero repare HTTPS primero (la caché, HSTS, las cookies y los service workers pueden hacer que una reversión real a HTTP sea insegura) y trate la preload de HSTS como algo lento y arriesgado de revertir en el plano operativo, no como una puerta literalmente de un solo sentido.

El hub de HTTPS cubre por qué conviene estar en HTTPS y esboza la migración a grandes rasgos. Este es el complemento profundo, paso a paso, de esa sección: la parte donde una migración se estropea de verdad o sale limpia.

Primero, dimensione el riesgo: esta es una migración solo de protocolo

Google trata los cambios de protocolo como mudanzas de sitio con cambios de URL; son posibles fluctuaciones temporales de posicionamiento o de los informes, y no se garantiza ningún plazo de migración. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: Site moves with URL changes La seguridad del transporte y el procesamiento de la Búsqueda son asuntos relacionados pero distintos. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: HTTPS

Las migraciones web se sitúan en un espectro de peligro. Cambiar su dominio, su estructura de URL o su CMS/plataforma reescribe la identidad de sus URLs y conlleva un riesgo real. Un cambio solo de protocolo es el caso de bajo riesgo únicamente cuando todo lo demás permanece estable. Confirme todo esto antes de tratarlo como una redirección de una sola regla:

  • Nombres de host: sin consolidación www/no-www ni cambios de subdominio acompañando al cambio.
  • Rutas y cadenas de consulta: sin reestructuración de URLs, renombrado de slugs ni limpieza de parámetros incluidos en la misma release.
  • Contenido: no se están reescribiendo, fusionando ni podando páginas al mismo tiempo.
  • Plataforma y comportamiento de renderizado: sin migración de CMS, framework ni alojamiento en paralelo.

Cuando se cumplen las cuatro condiciones, el dominio, las rutas y el contenido son idénticos; solo se mueve el esquema que precede a cada URL. Por eso Google es explícito al indicar que no hace falta la herramienta de cambio de dirección en este caso: no hay ningún cambio de dirección que declarar.

La consecuencia más importante: como las URLs se corresponden una a una y de forma determinista (http://example.com/x → https://example.com/x), su lógica de redirección puede ser normalmente una única regla de servidor, y su mapa de redirecciones se escribe solo. Compárelo con una mudanza de dominio o de plataforma, donde cada URL antigua necesita un destino comprobado a mano. Conserve ese enfoque: le dice dónde invertir esfuerzo (certificado, contenido mixto, Search Console) y dónde no (agonizar sobre los destinos de las redirecciones).

Si además va a cambiar de dominio o de plataforma al mismo tiempo, deténgase: es una migración apilada, los riesgos se multiplican y el cambio de protocolo es la menor de sus preocupaciones. Haga el movimiento más difícil con el manual completo de migración web e integre HTTPS en él.

Paso 1 — Mida la línea base del sitio HTTP en producción antes de tocar nada

No se puede saber si una migración salió bien sin una foto del «antes» con la que compararla. Capture, mientras el sitio sigue en HTTP:

  • Un rastreo completo del sitio en producción: guarde cada URL con 200 y, sobre todo, cada redirección existente y su destino. Volverá a ejecutar este rastreo después del lanzamiento y comparará ambos; todo lo que era 200 y ahora es 404 es una regresión.
  • Una instantánea de posiciones para sus palabras clave monitorizadas, para que una caída posterior al lanzamiento tenga una referencia.
  • Una exportación de Search Console: Performance (Informe “Rendimiento”: consultas, páginas, clics, impresiones), el informe Page Indexing (Informe “Indexación de páginas”) y Crawl Stats. Los datos de GSC no se transfieren de la propiedad HTTP a la HTTPS, así que esta exportación es su único registro del «antes».
  • Su perfil de backlinks, para saber qué URLs concentran más autoridad externa y, por tanto, más necesitan redirecciones limpias de un solo salto.
  • Su robots.txt y cualquier directiva noindex tal como están: querrá asegurarse de que ninguna se traslade silenciosamente y bloquee el sitio HTTPS.

Paso 2 — Elija e instale el certificado TLS

Esta es la verdad relevante para el SEO que ahorra dinero: la señal de posicionamiento comprueba el esquema de la URL, no el certificado. Gary Illyes lo describió como “basically looking at the first five characters in front of the URL, and if it’s HTTPS … it will get a minimal boost.” (traducción) «básicamente se miran los primeros cinco caracteres delante de la URL y, si es HTTPS…, recibirá un impulso mínimo». Así que, para el SEO, un certificado gratuito de validación de dominio (DV) —Let’s Encrypt es la opción por defecto— obtiene exactamente la misma señal que un certificado OV o EV de pago. OV/EV compran identidad organizativa, no posiciones. No se prometa (ni prometa a un cliente) una mejora de posicionamiento, ni un beneficio especial por un tipo de certificado o un algoritmo de clave concretos: la propia descripción de Google la califica como una señal ligera y mínima, no como una palanca por la que valga la pena pagar.

Lo que sí hay que hacer bien en el plano técnico:

  • Alcance. Un certificado de dominio único cubre un nombre de host; un comodín (*.example.com) cubre un solo nivel de etiqueta: funciona para foo.example.com pero no para foo.bar.example.com. Si utiliza subdominios profundos, planifique un certificado multidominio (SAN) o certificados adicionales.
  • Fortaleza de la clave. La recomendación de Google es “generate a 2,048-bit RSA key pair” (traducción) «genere un par de claves RSA de 2 048 bits»: más corta es vulnerable a fuerza bruta y más larga desperdicia recursos.
  • Renovación automática. El incidente posterior a la migración más habitual es un certificado caducado. Automatice la renovación (Let’s Encrypt está diseñado para ello) y monitorice la caducidad. Atención al matiz: Google normalmente prefiere HTTPS como versión de referencia de una página, pero esa preferencia es condicional, no automática: un certificado no válido, dependencias inseguras, una redirección de HTTPS a HTTP o una etiqueta HTTP de URL preferida pueden devolver la elección de URL preferida de Google a la URL HTTP, y HSTS no puede anular esa preferencia. Evidence for this claim Google generally prefers HTTPS as the canonical version of a page, but that preference is conditional: an invalid certificate, insecure dependencies, an HTTPS-to-HTTP redirect, or an HTTP canonical tag can flip Google's choice back to the HTTP URL. HSTS is a browser-only mechanism and cannot override Google's canonical selection. Scope: Describes Google's conditional HTTPS canonical preference, not a guarantee that certificate problems are search-invisible. Confidence: high · Verified: Google: Consolidate duplicate URLs Así que un certificado caducado no es un no-evento inocuo para la Búsqueda: es a la vez una emergencia de experiencia de usuario y seguridad (un aviso a pantalla completa del navegador que destruye la confianza del usuario) y un riesgo real para su preferencia de referencia HTTPS cuanto más tiempo persista. Corríjalo rápido en cualquier caso. (Para la taxonomía completa de fallos de certificado —caducado, autofirmado, nombre de host que no coincide, cadena incompleta— consulte el análisis a fondo de certificados TLS/SSL.)

Paso 3 — Ensaye en staging

Haga todo el cambio primero en una copia de staging o preproducción. Lo que está validando:

  • La regla de redirección se activa para todas las formas de ruta, incluidas las cadenas de consulta, las variantes con y sin barra final, y www/no-www.
  • Ningún bucle de redirección (una regla mal configurada que devuelve HTTPS a HTTP y vuelve a empezar deja a todo el mundo fuera, usted incluido).
  • Las páginas se renderizan limpias, sin contenido mixto bloqueable, en la consola de DevTools.
  • Sus etiquetas de URL preferida ya emiten https:// en staging.

Proteja la copia de staging de la indexación (autenticación o un noindex que recuerde eliminar: un noindex puesto solo para la migración que sobrevive hasta producción es una herida autoinfligida clásica). La propia guía de Google lo señala: no olvide eliminar los bloqueos de noindex o de robots.txt que solo eran necesarios para la migración.

Paso 4 — Mapeo de redirecciones a escala

Para un cambio de protocolo el mapeo es determinista, así que se gestiona con una sola regla, no con una tabla de búsqueda gigantesca:

  • Del lado del servidor, una a una y permanente (301). Cada URL http:// → la misma ruta en https://. Hágalo en la configuración del servidor o del edge (Apache, Nginx o su CDN), no en el código de la aplicación ni con JavaScript del lado del cliente, para que los bots vean una 301 limpia del servidor.
  • Sin cadenas de redirecciones. Si ya tenía redirecciones en HTTP (por ejemplo http://a → http://b), no permita que el cambio a HTTPS lo convierta en http://a → http://b → https://b. Actualice las reglas originales para que las URLs antiguas lleguen al destino HTTPS final en un solo salto. Google sigue hasta 10 saltos, pero recomienda redirigir directamente al destino final. Cada salto adicional es presupuesto de rastreo desperdiciado y algo de velocidad perdida.
  • Nunca redirija en masa a la página de inicio. Las URLs sin coincidencia deben seguir resolviéndose a su gemela HTTPS. Volcar todo en / es el error de migración que de verdad hace perder posiciones.
  • Verifique el mapa con un rastreo. Vuelva a rastrear la lista de URLs HTTP después del lanzamiento y confirme que cada una devuelve una única 301 a la URL HTTPS correcta: no una 302, no una cadena, no un 404.

Paso 5 — Reapunte cada señal de referencia, de sitemap y de hreflang

Las redirecciones hacen el trabajo pesado, pero no obligue a Google a apoyarse en ellas para arreglar una configuración interna descuidada. Actualice las señales reales:

  • URL preferidas. Cada página debe llevar una rel="canonical" autorreferencial que apunte a su propia URL https://: la guía de mudanzas de sitio de Google indica “Each new URL should have a self-referencing rel=“canonical” <link> tag.” (traducción) «Cada URL nueva debe tener una etiqueta link de URL preferida autorreferencial». Una etiqueta de URL preferida que sigue apuntando a http:// juega en contra de su migración. (Este es exactamente el tipo de señal contradictoria del que advierte el tema de canonicalización: alinee todas las señales con la URL HTTPS.)
  • Enlaces internos. Cámbielos en las plantillas y en el contenido a https:// (o a rutas relativas al protocolo o a la raíz); no deje miles de enlaces internos apuntando a http:// confiando en que la redirección lo limpie. Cada enlace interno http:// es un salto de redirección innecesario para usuarios y bots.
  • Sitemaps XML. Regenérelos solo con las URLs HTTPS, listando páginas de referencia e indexables, y actualice lastmod. Envíe el nuevo sitemap en GSC después del lanzamiento.
  • Hreflang. Si tiene una configuración internacional, cada anotación hreflang debe referenciar la versión HTTPS de cada alternativa. Un hreflang a medio migrar (unas http, otras https) es un error de SEO internacional silencioso y difícil de diagnosticar.
  • Datos estructurados y URLs de Open Graph. og:url, las URL de referencia dentro de JSON-LD y cualquier URL absoluta codificada a mano deben ser HTTPS.

Paso 6 — Elimine el contenido mixto antes del lanzamiento, no después

El contenido mixto es una página HTTPS que carga un subrecurso por HTTP. Es la regresión más habitual del día del lanzamiento. La terminología actual (la antigua división «activo/pasivo» es histórica, pero seguirá viéndola en documentación y herramientas más viejas) lo divide según lo que hace el navegador al respecto:

  • Contenido mixto bloqueable: scripts, hojas de estilo, iframes, XMLHttpRequest/fetch (el antiguo grupo «activo»). Los navegadores los bloquean directamente, porque un script manipulado puede reescribir toda la página. Esto es lo que de verdad rompe el sitio tras el cambio: una hoja de estilo o un bundle de JS bloqueados pueden dejar una página sin estilos o sin funcionar. Corrija esto primero.
  • Contenido mixto actualizable (bloqueable de forma opcional): imágenes, audio, vídeo (el antiguo grupo «pasivo»). Los navegadores modernos actualizan automáticamente cada vez más estas peticiones a HTTPS de forma transparente y las bloquean si la actualización falla, en lugar de limitarse a avisar y mostrarlas por HTTP; considere que «sigue cargando» es un comportamiento que depende de la versión del navegador, no una garantía. Corríjalo a continuación en cualquier caso.
  • Existen excepciones: algunos contextos de navegador o de incrustación (ciertos recursos cargados por plugins, algunos casos heredados de <applet>/<embed>) no siguen ninguna de las dos reglas de forma limpia, lo que es una razón más para verificar el comportamiento en los navegadores que su audiencia usa realmente en lugar de dar por supuesta la regla general.

Encuéntrelo rastreando el sitio HTTPS (Ahrefs Site Audit, Screaming Frog), vigilando la consola de Chrome DevTools o recogiendo informes de CSP. Como red proactiva de transición, la cabecera Content-Security-Policy: upgrade-insecure-requests indica al navegador que actualice silenciosamente las peticiones de subrecursos http:// a https:// antes de realizarlas, pero una cabecera CSP no demuestra que la versión HTTPS de cada endpoint exista realmente ni que se comporte igual que la HTTP, y no sustituye a corregir las URLs de origen ni a probar en navegadores reales. Una aclaración que evita confusiones: un enlace de anclaje normal a una página HTTP no es contenido mixto; simplemente navega.

Paso 7 — Configure bien la cobertura de Search Console

Este es el paso que la gente subestima, pero es una decisión, no una lista de comprobación universal. Las URL-prefix properties de Search Console tratan http://example.com, http://www.example.com, https://example.com y https://www.example.com como cuatro propiedades separadas que no comparten datos. No está obligado a verificar las cuatro:

  • Una Domain property agrega automáticamente todas las variantes de protocolo y subdominio: añada una y absorberá el cambio sin que tenga que tocar nada más. Es el valor por defecto más sencillo para la mayoría de sitios.
  • Las URL-prefix properties segmentan los datos por protocolo y host exactos. Consérvelas o añádalas solo si quiere deliberadamente esa segmentación; por ejemplo, para comparar cuánto tráfico rezagado sigue llegando por HTTP frente al sitio HTTPS en producción. Es una decisión de reporting, no un requisito.

En cualquiera de los dos casos:

  • Envíe el nuevo sitemap HTTPS allí donde esté monitorizando el sitio (la Domain property o la URL-prefix property de HTTPS).
  • No use la Change of Address tool. Google es explícito: “If you’re moving your site from HTTP to HTTPS, you don’t need to use the Change of Address tool.” (traducción) «Si está moviendo su sitio de HTTP a HTTPS, no necesita usar la Change of Address tool». Esa herramienta es solo para mudanzas a nivel de dominio, y usarla aquí es un error bienintencionado.
  • Mantenga verificadas las propiedades HTTP que ya tuviera: mostrarán cómo se procesan las redirecciones y cómo las URLs antiguas salen del índice, lo que es una señal útil de monitorización, no ruido.
  • Revise su archivo disavow, si tiene uno: sus entradas referencian URLs HTTP y vive por propiedad.

Para diagnosticar URLs individuales en lugar de monitorizar todo el sitio, el HTTPS report de GSC señala los motivos —certificado, redirección, de referencia, robots y evaluación del sitemap— por los que una URL no pasó a HTTPS. Trátelo como una herramienta de diagnóstico por muestreo, no como un inventario completo: se basa en muestras e ignora los parámetros de consulta al emparejar URLs, así que no detectará todo lo que sí vería su propio rastreo. Consulte el análisis a fondo del HTTPS report de GSC para saber cómo leerlo.

Paso 8 — Ventanas de monitorización: asentamiento frente a rotura

Espere una “temporary fluctuation in site ranking during the move” (traducción) «fluctuación temporal en el posicionamiento del sitio durante la mudanza»: es normal y no es motivo para entrar en pánico ni revertir. La disciplina consiste en distinguir una caída de asentamiento de una caída por rotura:

  • Una caída que se recupera en días o unas pocas semanas es el índice intercambiando URLs HTTP por HTTPS. Google señala que en un sitio pequeño o mediano la mayoría de las páginas tardan unas semanas en moverse; los sitios más grandes tardan más.
  • Una caída que se mantiene significa que algo se rompió: un bloqueo olvidado en robots.txt, un noindex que sobrevivió desde staging, de referencia que siguen apuntando a http://, enlaces internos masivamente en HTTP, o cadenas de redirecciones que sangran autoridad.

No hay una ventana de recuperación fija; siga estos indicadores de forma independiente en lugar de esperar a que un solo número diga «listo»:

  • Comportamiento de TLS y del navegador: validez y cadena del certificado, y la consola real de las herramientas de desarrollo en páginas representativas (sin errores de contenido mixto, sin avisos de certificado). Este es el que las métricas de Búsqueda no le contarán.
  • Estadísticas de rastreo de GSC allí donde monitorice el sitio: quiere ver a Googlebot solicitando las URLs HTTPS y una mezcla de códigos de estado sana (mayoritariamente 200 más las 301 en las URLs antiguas). Un pico de 5xx significa que su servidor está sufriendo con la nueva carga.
  • Informe de indexación de páginas: las URL HTTPS pasando a «Indexadas» y las HTTP a «Página con redirección». Ese cruce es exactamente lo que quiere ver.
  • URL Inspection en unas cuantas páginas clave: confirme que la URL preferida declarada es la URL HTTPS y que la página se renderiza sin contenido mixto.
  • Registros del servidor: la verdad sobre el terreno de qué URLs visitan realmente los bots y qué código de estado reciben. Vigile bots que sigan insistiendo en URLs HTTP (aceptable, brevemente) o que caigan en cadenas y bucles (no aceptable).
  • Analítica y resultados de negocio: puede aparecer una parte del tráfico como «directo» porque los datos de referencia de HTTPS→HTTP se eliminan, así que asegúrese de que sus propios enlaces salientes apunten a destinos HTTPS; monitorice además las conversiones y los ingresos de forma independiente: que una métrica de posicionamiento se recupere no garantiza que las métricas de negocio también lo hayan hecho.

Monitorice activamente durante 2 a 4 semanas como regla general y después mantenga una vigilancia más ligera hasta que la indexación cruce por completo: los sitios más grandes o rastreados con menos frecuencia pueden tardar más, y no hay fecha de finalización garantizada.

Paso 9 — Conserve las redirecciones y añada HSTS de forma deliberada

  • Conserve las 301 a largo plazo. La recomendación de Google es “as long as possible, generally at least 1 year” (traducción) «tanto tiempo como sea posible, en general al menos 1 año»: es un mínimo que Google recomienda, no una fecha de caducidad tras la cual sea seguro eliminarlas. En la práctica, consérvelas durante toda la vida del sitio: los enlaces externos y los marcadores a las URLs http:// antiguas nunca desaparecen del todo.
  • HSTS es una segunda capa, no un sustituto. La cabecera Strict-Transport-Security indica a los navegadores que usen siempre HTTPS para su dominio, lo que cierra el «problema de la primera petición» (esa primerísima petición de un visitante nuevo sale por HTTP antes de que se dispare la 301, la ventana que busca un atacante de SSL stripping). Pero cuando un navegador respeta HSTS realiza una redirección interna 307 exclusiva del navegador que los rastreadores nunca ven: los motores de búsqueda siguen necesitando su 301 del lado del servidor. Necesita ambas.
  • Trate la preload de HSTS como algo lento y arriesgado de revertir, no como una puerta literalmente de un solo sentido. Enviarla a la lista de preload integrada en los navegadores (que exige un max-age de al menos un año, includeSubDomains —lo que significa que la política se aplica a todos los subdominios, no solo al que envió, así que cualquier subdominio que no esté totalmente listo para HTTPS se rompe con ella— y preload) cierra el hueco incluso para los visitantes primerizos. La eliminación es realmente posible a través de hstspreload.org, pero es lenta (el cambio tiene que propagarse por los ciclos de publicación de los navegadores) y todos los navegadores que ya tengan la lista antigua siguen imponiendo solo HTTPS hasta que se actualicen: arriesgado en el plano operativo, no literalmente irreversible. El aviso de Google es rotundo: “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (traducción) «No habilite HSTS hasta que esté seguro de que la operación de su sitio es lo bastante robusta para no desplegar nunca HTTPS con errores de validación de certificado».

Paso 10 — Tenga un plan de reversión (y conozca sus límites)

Incluso una migración de bajo riesgo merece una salida, pero la acción por defecto cuando algo se rompe es reparar HTTPS, no volver a HTTP. Una «reversión» es una red de seguridad limitada, no una vuelta atrás garantizada: las 301 en caché en navegadores y CDNs, las cookies con la marca Secure, los service workers registrados bajo el origen HTTPS y la política de HSTS o de preload pueden hacer que volver a servir HTTP sea inseguro o simplemente inútil para una parte de sus visitantes, incluso si lo hizo todo bien en el lanzamiento.

Antes de hacer el cambio:

  • Programe el lanzamiento en un momento de poco tráfico: Google sugiere explícitamente que se programe la mudanza para un periodo de poco tráfico. Una ventana tranquila implica que menos usuarios se topen con cualquier fallo del día del lanzamiento y le da margen para reaccionar.
  • Mantenga HTTP sirviendo por debajo de la redirección. No desmonte el listener HTTP; manténgalo vivo para que las 301 tengan algo desde donde dispararse y para que revertir la regla de redirección siga disponible como opción si el sitio HTTPS está muy roto.
  • No habilite HSTS el primer día. HSTS (y especialmente la preload) hace mucho menos viable una reversión a HTTP: una vez que un navegador ha guardado la política, no hablará HTTP con su dominio por más que cambie su servidor. Añada HSTS solo después de que el sitio HTTPS haya demostrado estabilidad durante un tiempo.
  • Defina sus criterios de aborto por adelantado: por ejemplo, 5xx en todo el sitio, un bucle de redirección o bloqueo masivo por contenido mixto. Cuando los alcance, trabaje el problema en este orden: (1) ¿puede corregir el fallo de HTTPS directamente (certificado incorrecto, recurso ausente, de referencia rota)? Normalmente sí, y eso es más rápido y seguro que revertir. (2) Solo si HTTPS en sí es inutilizable, revierta la regla de redirección como medida provisional, y espere que sea incompleta: las redirecciones ya en caché, las cookies y los service workers no se descachean solos porque su servidor haya cambiado de opinión.

Diagnostique con calma en lugar de depurar en producción, y trate «volver a HTTP» como una opción de emergencia que espera no necesitar nunca, no como una vuelta atrás rutinaria y limpia.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.