Conversión HTTPS de WordPress: Pase de HTTP a HTTPS de forma segura y correcta

WordPress HTTPS protege los datos de inicio de sesión, formularios de contacto y cookies y me ayuda a aumentar el ranking y la conversión. En esta guía, te mostraré el cambio completo de HTTP a HTTPS en WordPress - con certificado, conversión de URL, redireccionamientos 301, corrección de contenido mixto y pasos limpios de SEO.

Puntos centrales

• SSL Activar correctamente y cubrir el dominio
• URL convertir a WordPress
• 301 Forzar el reenvío
• Contenido mixto Rectificación selectiva
• SEO volver a apretar y comprobar

Por qué HTTPS es importante para WordPress

Sin cifrado, los atacantes pueden secuestrar sesiones o leer formularios, razón por la cual aseguro todo el Transmisión entre el navegador y el servidor con TLS. HTTPS evita advertencias en el navegador, aumenta la confianza y refuerza las señales que los motores de búsqueda valoran positivamente. De todos modos, muchas API, servicios de pago y funciones del navegador requieren conexiones seguras. También me beneficio de HTTP/2 y HTTP/3, que cargan más rápido con TLS y permiten la paralelización. Un cambio limpio a HTTPS evita el contenido duplicado, porque puedo restringir todas las variantes a un único Cañón (Canónico).

Preparar copia de seguridad y certificado SSL

Antes de tocar ninguna configuración, hago una copia de seguridad completa de los archivos y la base de datos para poder acceder a ellos en cualquier momento. Copia de seguridad puede devolver. Entonces pido o activo un certificado - Let's Encrypt suele ser suficiente sin coste adicional, alternativamente utilizo un certificado DV/OV/EV dependiendo de mis necesidades. Muchos hosters ofrecen un asistente que emite y renueva los certificados automáticamente. Si necesitas ayuda paso a paso, utiliza este tutorial en la página web de Configurar SSL gratuito. A continuación, compruebo si la cadena del certificado está completa y si tanto los dominios www como apex (sin www) están cubiertos por el certificado; también tengo en cuenta subdominios como staging o cdn y mantengo sus Validez de un vistazo.

Selección de certificados y gestión de claves

Además de la activación inicial, también observo algunos detalles que faltan en muchas instrucciones: ¿Necesito un certificado comodín (*.dominio.tld) para muchos subdominios o basta con un certificado SAN con varios nombres de host explícitos? Por motivos de rendimiento, utilizo certificados ECDSA (curvas elípticas) en lugar de claves RSA clásicas siempre que es posible: son más pequeños y aceleran el protocolo TLS. Protejo estrictamente la clave privada (permisos de fichero 600, sólo usuarios del servidor), y documento el Renovación-cadena: ¿la renovación automática se realiza realmente, aunque haya una CDN o un proxy inverso conectado en sentido ascendente? Para los retos de ACME, compruebo si las redirecciones, los límites de tarifa o las páginas de mantenimiento interfieren con la validación. También activo el grapado OCSP y los protocolos modernos (TLS 1.2/1.3) directamente en el servidor web para que los navegadores puedan procesar las comprobaciones de certificados más rápidamente.

Cambiar las URL de WordPress

Me conecto al panel de control y abro Ajustes → General, luego configuro "Dirección de WordPress (URL)" y "Dirección del sitio web (URL)" como https://. Después de guardar, me conecto de nuevo si se reinicia la sesión. Después borro la caché del navegador y, si está disponible, la caché de mi plugin de caché para que los visitantes reciban inmediatamente la versión segura. A continuación, echo un vistazo a los widgets, menús y enlaces duros, ya que todavía pueden contener enlaces http. En cuanto al contenido multimedia de las entradas, edito el contenido individual o planifico una limpieza. Buscar en en la base de datos (véase más abajo).

Inicio de sesión y administración seguros

Para el área de administración, aplico TLS con una pequeña adición en el archivo wp-config.php. Para ello, añado lo siguiente encima de la línea "/* ¡Eso es todo, deja de editar! */" y subo el archivo:

define('FORCE_SSL_ADMIN', true);

Esto significa que el inicio de sesión, las cookies y todo el backend se ejecutan estrictamente a través de HTTPS. Si se conecta un proxy inverso o una capa CDN, me aseguro de que WordPress interpreta correctamente el encabezado "X-Forwarded-Proto: https". De lo contrario, la aplicación trata incorrectamente la conexión como insegura y establece cookies sin Asegure-bandera.

Constantes de WordPress más seguras y detección de proxy

Si no puedo acceder a las URL en el backend (por ejemplo, a través de un bucle de plugins), establezco temporalmente constantes explícitas en wp-config.php y elimino así las configuraciones incorrectas:

define('WP_HOME', 'https://deinedomain.de');
define('WP_SITEURL', 'https://deinedomain.de');

También añado detección detrás de proxies para que is_ssl() correctamente:

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Esto evita la generación incorrecta de contenido mixto en el backend y garantiza que las cookies de autenticación estén vinculadas de forma coherente a los archivos Asegure-atributo se entregan.

Configurar redireccionamientos 301 en .htaccess

Para asegurarme de que todas las peticiones van permanentemente a la versión segura, configuré un archivo Reenvío de http a https. En un entorno Apache clásico, abro el .htaccess en la raíz de WordPress y añado las reglas encima del bloque de WordPress:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Con Nginx, el reenvío tiene lugar en la configuración del servidor (server { listen 80; return 301 https://$host$request_uri; }). Para más detalles, variantes y resolución de problemas, puedes encontrar una guía clara en la sección Reenvío HTTPS. Importante: Mantengo la cadena de redireccionamiento corta, es decir, http→https y, si es necesario, www→non-www o viceversa en un solo salto, para que no haya saltos innecesarios en la cadena de redireccionamiento. Tiempo de carga aumentar.

Estrategia de redirección limpia sin bucles

Además del reenvío básico, establezco reglas de coherencia: O www o no www - nunca ambos. Con Apache, resuelvo esto en un solo paso con una comprobación de host:

RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^deinedominio.de$ [NC]
RewriteRule ^ https://deinedomain.de%{REQUEST_URI} [L,R=301]

Recibo las cadenas de consulta (parámetros UTM) automáticamente, reduzco las redirecciones a un salto y evito bucles al no activar ninguna regla competidora en el plugin o CDN. Si un proxy de borde utiliza "Flexible SSL" (Browser→CDN encrypted, CDN→Origin unencrypted), cambio a "Full (strict)" para que TLS se aplique tanto para el visitante como para el origen - de lo contrario hay riesgo de problemas de bucles y protocolos mixtos.

Reconocer y eliminar los contenidos mixtos

Después de la redirección, compruebo la página con las herramientas del navegador en busca de "contenido mixto", es decir, contenido al que todavía se puede acceder a través de http se cargan. Las imágenes, las fuentes, los scripts o las hojas de estilo de los temas, los creadores de páginas o los widgets suelen verse afectados. Corrijo las URL codificadas cambiándolas a https en el editor, en el personalizador o en la configuración del plugin. Herramientas como "Really Simple SSL" ayudan a corto plazo, pero es mejor una limpieza permanente de las fuentes. El contenido bloqueado provoca errores de estilo o funciones ocultas, así que lo limpio todo hasta que el navegador no bloquea ningún contenido. Advertencias muestra más.

Lista de control profesional de contenido mixto

• Activo la directiva CSP como prueba upgrade-insecure-requests en modo sólo informe para ver lo que el navegador actualiza automáticamente a https - luego limpio permanentemente las fuentes.
• Las fuentes y los estilos externos suelen requerir cabeceras CORS; sin Access-Control-Allow-Origin aparecen como bloqueados.
• Reconozco las imágenes de fondo CSS con enlaces http absolutos en las herramientas para desarrolladores y las sustituyo por rutas relativas o https.
• Los iframes (por ejemplo, mapas, vídeos) también deben hablar https, de lo contrario el navegador los ocultará.
• En los temas, evito las rutas codificadas y utilizo funciones como home_url(), site_url(), plugins_url() y content_url()para que WordPress proporcione la URL base correcta.

Resumen paso a paso

El siguiente cuadro resume de forma compacta todas las tareas relacionadas con el cambio y me ayuda a Secuencia cumplir.

Paso	Recomendación/explicación
Crear copia de seguridad	Antes de cada cambio, complete Copia de seguridad de archivos y base de datos
Configurar certificado SSL	Activar Let's Encrypt o la versión de pago con el hoster
Personalizar las URL	Configure https en el backend en Ajustes → General.
Establecer redireccionamientos	Configurar .htaccess o bloque de servidor Nginx para 301 a HTTPS
Comprobar el contenido mixto	Sustituir enlaces http duros en contenidos, temas y plugins
Sustituir base de datos	Reemplazar todas las ocurrencias http con una copia de seguridad y una herramienta de confianza
Actualizar Google/SEO	Personalizar las propiedades de Search Console, el mapa del sitio, los análisis y los canónicos

Sustituya limpiamente las URL de las bases de datos

A veces los enlaces http permanecen inactivos en widgets, shortcodes o campos definidos por el usuario, por lo que utilizo un método de eficacia probada Herramienta como "Better Search Replace". Busco "http://deinedomain.de" y lo reemplazo por "https://deinedomain.de", primero en un simulacro, luego de verdad con una copia de seguridad. Para renombrar en serie vía WP-CLI, uso "wp search-replace", que es mucho más rápido para páginas grandes. Las matrices y objetos serializados deben manejarse correctamente, por lo que confío en herramientas que manejen esto adecuadamente. Después del intercambio, compruebo muestras aleatorias en el frontend y en importantes Diseños.

Base de datos: Lo que no sustituyo a ciegas

Sólo toco la columna GUID en el wp_posts cuando realmente cambio el dominio. El puro cambio de protocolo a https normalmente requiere ninguno Cambiar los GUID, ya que sirven principalmente como identificador único. Antes de un reemplazo global, también compruebo si los plugins hacen referencia a puntos finales externos (webhooks, APIs) con http - prefiero actualizarlos específicamente y probar el canal de retorno. Para proyectos grandes, planifico una breve fase de congelación de contenidos para que no se creen nuevos posts con esquemas antiguos durante el reemplazo de búsqueda. Utilizo WP-CLI para garantizar la rapidez y la reproducibilidad:

wp search-replace 'http://deinedomain.de' 'https://deinedomain.de' --all-tables-with-prefix --precise --dry-run
wp search-replace 'http://deinedomain.de' 'https://deinedomain.de' --all-tables-with-prefix --precise

Comprobaciones SEO tras el cambio

Tras el cambio, creo una nueva propiedad con https en Search Console y envío una actualización Mapa del sitio en. Compruebo los enlaces internos, las etiquetas canónicas, las referencias hreflang y las etiquetas open graph para https. Los fragmentos de seguimiento (analytics, tag manager, pixel) también deben utilizar la dirección segura. En los plugins SEO, compruebo las reglas de redirección y me aseguro de que no haya "soft 404s". Si los contadores de acciones sociales son importantes, pruebo cómo funciona la herramienta con el nuevo Dirección asas.

Ajustar feeds, robots y canónicos

Compruebo si los canales RSS/Atom son accesibles a través de https y ofrecen contenidos válidos. En un robots.txt mantenido estáticamente, adapto las rutas del mapa del sitio a https si es necesario. Configuro las URL canónicas de forma coherente y absoluta con https para que los motores de búsqueda interpreten las señales sin ambigüedades. Los pares hreflang (sitios multilingües) no deben diferir en el protocolo, de lo contrario surgen incoherencias.

Caché, CDN y rendimiento en HTTPS

HTTPS también merece la pena en términos de velocidad, ya que HTTP/2/3 permite la multiplexación y la compresión de encabezados a través de un Conexión. Presto atención a la reanudación de sesión TLS, al grapado OCSP y a las suites de cifrado modernas, lo que acelera los apretones de manos. Una CDN entrega activos estáticos más cerca del visitante, pero debe funcionar siempre en https. En los plugins de caché, activo la opción "Caché para HTTPS", si está disponible, y borro los artefactos antiguos. Luego mido con herramientas como Lighthouse y comparo el Times antes y después del cambio.

Funciones CDN/Proxy

Con un CDN upstream, siempre configuro "Completo (estricto)" en Origen, subo el certificado allí o uso un certificado de Origen y sólo permito que se entregue https. Compruebo si la CDN almacena en caché las redirecciones (de lo contrario, veo estados antiguos) y borro las cachés de borde tras el cambio. La compresión Brotli, HTTP/3/QUIC y 0-RTT también pueden ayudar, pero es importante que las reglas a nivel de página ya no inyecten recursos http. Por último, envío el IP del cliente-(por ejemplo, X-Forwarded-For) y configure el servidor web para que los registros muestren la IP real del visitante.

HSTS y otras cabeceras de seguridad

Si el sitio se ejecuta íntegramente en HTTPS, activo HTTP Strict Transport Security (HSTS) para que los navegadores sólo utilicen el protocolo HTTPS-variante. Por ejemplo, yo configuro el encabezado así Strict-Transport-Security: max-age=31536000; includeSubDomains; preload - pero sólo si todos los subdominios son realmente accesibles de forma segura. Para oportunidades y escollos, recomiendo la guía Activar HSTS. Además, establezco cabeceras de seguridad como X-Content-Type-Options, X-Frame-Options y una estricta política de seguridad de contenidos que permite fuentes https. Estas cabeceras refuerzan las capas de protección contra la inyección de contenidos, clickjacking y MIME-Olfateando.

Ajuste de la cabecera de seguridad

Además de HSTS, añado una configuración de cabecera pragmática: Política de referenciación: origen estricto en caso de origen cruzado limita la transferencia de vías sensibles, Política de permisos restringe las API del navegador (por ejemplo, cámara, micrófono), y un CSP moderado con default-src 'self' https: evita fuentes ajenas no deseadas. Empiezo con Sólo informesRecopilo las infracciones y luego endurezco las directrices. Así evito que las cabeceras de seguridad "rompan" involuntariamente el sitio.

Pruebas, supervisión y resolución de problemas

Estoy probando el cambio en una ventana privada y en dispositivos móviles para que ningún antiguo Cookies o cachés. El registro de la consola del navegador muestra rápidamente advertencias de contenido mixto y recursos bloqueados. Utilizo "curl -I http://deinedomain.de" para comprobar si se produce un 301 a la versión https y si se producen otras cadenas. A continuación, controlo los registros de errores en el servidor y los informes 404 en el plugin SEO o en Search Console. Si algunos plugins dejan de cargarse, compruebo si son externos. Dependencias y actualízalo a la última versión.

Control de entrada en funcionamiento y seguimiento continuo

• Opcionalmente activo un breve modo de mantenimiento antes de cambiar para establecer redireccionamientos y cachés coherentes.
• Controlo la caducidad de los certificados (alarmas) para que no haya sorpresas desagradables.
• En los primeros días, controlo el índice 404, las curvas de clasificación, las estadísticas de rastreo y Core Web Vitals para tomar contramedidas tempranas.
• Para las campañas, compruebo si los parámetros UTM se conservan íntegramente mediante la redirección 301.

Características especiales de multisitio, proxy y staging

Para multisitios, cambio la dirección de red a https y ajusto las asignaciones para que todos los sitios tengan una dirección uniforme. Reenvío uso. Detrás de balanceadores de carga o CDNs, el servidor web debe observar la cabecera "X-Forwarded-Proto", de lo contrario WordPress pensará que la conexión es insegura y establecerá las URLs incorrectas. Para los sistemas de staging, utilizo mis propios certificados o los protejo con Basic Auth para que los motores de búsqueda no los indexen. Tras el cambio en vivo, vuelvo a activar las cachés, las caliento y controlo la carga. En los entornos con sus propios proxies o cortafuegos, documento todos los cambios para que las implantaciones posteriores puedan utilizar el Configuración hacerse cargo.

Detalles sobre multisitios y comercio que suelen faltar

En configuraciones multisitio actualizo por sitio el siteurl y Inicio especialmente si se trata de la asignación de dominios. Si un amanecer.php o plugins de mapeo especiales, compruebo si son compatibles con https. En las tiendas (p. ej., WooCommerce), configuro sistemáticamente "Pago" y "Mi cuenta" en https, pruebo el pago y Gancho web-devoluciones y páginas de agradecimiento. Los proveedores de pago y las API de envío suelen requerir URL de devolución de llamada actualizadas: las personalizo y verifico la comprobación de la firma tras el cambio.

Errores comunes y soluciones rápidas

Los certificados incorrectos provocan señales rojas de advertencia. Por ello, compruebo el periodo de emisión, la cadena y si todos los dominios están incluidos en el certificado para que el Conexión funciona sin interrupción. Las redirecciones 301 que faltan crean contenido duplicado; lo regulo con reglas claras y cortas y evito los saltos múltiples. El contenido mezclado a menudo proviene de archivos temáticos codificados; aquí reemplazo los esquemas http o utilizo URLs sin esquema ("//...") en los lugares apropiados. Los servicios externos que aún hacen referencia a peticiones http bloquean; aquí actualizo webhooks, endpoints y claves. Si un plugin no puede gestionar el cambio, pruebo una actualización o lo sustituyo por una solución que soporte HTTPS por completo. Admite.

Resumen: Cambio seguro a HTTPS

Empiezo con una copia de seguridad completa, activo el CertificadoCambio las URL de WordPress a https, aplico redireccionamientos 301 y limpio sistemáticamente el contenido mixto. A continuación, reemplazo las entradas http restantes en la base de datos, actualizo la configuración SEO y mido el rendimiento. HSTS y las cabeceras de seguridad aumentan aún más la seguridad, siempre que todos los subdominios respondan correctamente a https. Para el alojamiento, confío en proveedores con buen soporte, renovación automática y aprovisionamiento TLS rápido, como webhoster.de, que me facilita mucho el trabajo. Esto mantiene el sitio seguro, rápido y visible, que es exactamente lo que espero de un sitio web sostenible. HTTPS-cambio.