Evaluación inicial sin contraseñas Presupuesto antes de intervenir Especialista responsable de principio a fin

Hosting Dns Ssl

Persisten avisos de contenido mixto tras pasar WordPress a HTTPS

Elimina contenido mixto de WordPress localizando recursos HTTP en la base de datos, tema, CSS, CDN e integraciones.

Una página HTTPS tiene contenido mixto cuando solicita por HTTP una imagen, hoja de estilos, script, fuente, frame o API. Los navegadores bloquean el contenido activo con más rigor, de modo que el aviso también puede romper funciones.

Localiza cada fuente con evidencias del navegador. Un plugin que reescribe la salida puede ocultar URLs antiguas sin corregir dónde están guardadas.

Inventaría las peticiones bloqueadas

Abre Consola y Red en páginas representativas y registra URL HTTP, tipo, iniciador y página.

Posibles fuentes:
contenido de entradas y páginas
archivos de tema o plugin
CSS inline o generado
ajustes de Personalizador o constructor
widgets y opciones
CDN e integraciones externas

No copies URLs con tokens privados o identificadores de clientes.

Confirma los ajustes HTTPS canónicos

Revisa que home, siteurl y las constantes utilicen HTTPS. Asegura que el proxy comunica correctamente el protocolo o WordPress seguirá generando HTTP.

Prueba wp_upload_dir(), medios, login y administración. Corrige el ajuste de origen antes de reemplazar contenido. Evita crear un bucle de redirección al modificar servidor o proxy.

Busca en la base de datos con seguridad

Haz una copia y ejecuta una simulación compatible con serialización:

wp search-replace 'http://example.com' 'https://example.com' --all-tables-with-prefix --dry-run

Revisa tablas y cantidades y limita después la sustitución. No modifiques GUID salvo que la política de migración lo requiera.

No reemplaces globalmente cualquier http://: algunos servicios no soportan TLS y podrías dañar datos codificados o firmados.

Inspecciona tema y plugins propios

Busca URLs HTTP incrustadas en el tema hijo y plugins personalizados, endpoints de API y estilos o scripts inline.

Usa funciones de WordPress y https:// para servicios seguros conocidos. Las URLs relativas al protocolo no arreglan un host externo sin TLS.

No edites temas padre ni dependencias del proveedor; corrige código mantenido o actualiza su versión.

Revisa CSS generado y constructores

Los constructores guardan fondos y fuentes absolutas y compilan CSS en uploads o caché. Cambia el ajuste fuente y regenera el CSS.

Limpia únicamente las cachés relevantes y comprueba permisos de escritura. No edites archivos compilados manualmente. Prueba cada idioma y plantilla porque pueden conservar valores separados.

Inspecciona bloques, patrones y widgets

Bloques de navegación, patrones sincronizados, widgets antiguos y HTML personalizado pueden almacenar recursos aparte del contenido ordinario.

Busca sus tipos y opciones con herramientas conscientes de serialización. No reemplaces ejemplos de código o texto del usuario que contenga http:// intencionadamente. Republica y prueba todas las páginas que reutilicen el patrón.

Comprueba correos, feeds y sitemaps

Emails transaccionales, RSS, Atom y sitemaps pueden mantener enlaces HTTP aunque las páginas estén limpias. Genera ejemplos nuevos después de actualizar.

Revisa plantillas SMTP o newsletter y feeds en caché. No reescribas URLs firmadas de baja o seguimiento sin soporte del proveedor. Comprueba también los mensajes en texto plano.

Revisa CDN y offload

El dominio de medios necesita su propio certificado válido y un origen HTTPS correcto. Actualiza la configuración de offload o CDN, no solo el contenido.

Purga después de cambiar y verifica que ningún redirect vuelva a HTTP. Para fuentes personalizadas, revisa CORS además del protocolo.

Sustituye recursos externos solo HTTP

Usa el endpoint HTTPS oficial, aloja una copia local si la licencia lo permite, utiliza un proxy mantenido y seguro o elimina la dependencia.

No desactives la protección del navegador ni añadas excepciones CSP inseguras. Tampoco hagas proxy de API sensibles sin comprender autenticación y tratamiento de datos. Documenta cualquier función retirada.

Verifica todos los tipos de página

Rastrea entradas, plantillas, CSS, feeds, emails y recursos del editor. Comprueba Consola en móvil y escritorio con la caché caliente.

upgrade-insecure-requests o CSP en modo report-only pueden ser controles adicionales después de reparar el origen, no sustitutos. La migración termina cuando cada recurso nace con una URL segura.

ANTES DE ENVIAR LA SOLICITUD

Preguntas frecuentes.

¿Pedís contraseñas en el formulario?+

No. El formulario público nunca solicita accesos. Los datos seguros se piden únicamente después de aprobar el alcance y el presupuesto.

¿Quién revisa la incidencia?+

La solicitud llega a Jordi Ensenyat, fundador de Code Barcelona y especialista WordPress con más de 15 años de experiencia.

¿Se cambia algo antes del presupuesto?+

No. Primero se revisan los síntomas visibles y se define el alcance. La intervención empieza tras la aprobación y con una vía de vuelta preparada.

¿Trabajáis con webs en inglés y fuera de España?+

Sí. WP Repair atiende incidencias WordPress y WooCommerce en inglés y español, con servicio remoto.

Evaluar mi incidencia