Qué importa primero: La advertencia contiene dos ubicaciones: donde comenzó la salida y donde WordPress más tarde intentó enviar un encabezado. Repare la primera ubicación, no la llamada aguas abajo de cookie o redireccionamiento.
Qué indica realmente este síntoma
Whitespace, un UTF-8 BOM, eco de depuración, advertencia o accidental HTML puede iniciar la salida temprano. El síntoma visible puede ser fallo de acceso, redireccionamientos rotos, errores de alimentación o una advertencia expuesta.
Recopila pruebas antes de cambiar nada
- Captura el mensaje completo, incluyendo el archivo y la línea “salida start at”.
- Inspecciona el archivo en un editor hex-aware para un BOM o espacio en blanco antes de <?php.
- Comprueba logs para obtener una advertencia anterior que se imprima antes de la operación de cabecera.
- Compara el archivo con su versión limpia o historial de control de versiones.
Causas más habituales
- Espacio en blanco o BOM: Los bytes invisibles antes de la etiqueta de apertura PHP se envían inmediatamente.
- Salida de depuración: var_dump, echo o print_r permanece en el código de producción.
- Alerta previa: Un aviso o deprecación se muestra y se convierte en la primera salida.
- Cierre de la etiqueta PHP: Whitespace después de?> en un archivo solo PHP puede filtrarse en la respuesta.
Secuencia segura de diagnóstico y reparación
- Quitar solo la salida no deseada y mantener los archivos solo PHP sin una etiqueta de cierre.
- Desactivar display_errors en la producción mientras se mantiene protegido el registro.
- Restaurar el plugin limpio, tema o el archivo de núcleo cuando la modificación no se explica.
- Prueba la acción que necesita encabezados: iniciar sesión, redirigir, cookie o respuesta de alimentación.
Cómo distinguir entre las causas probables
No trates Espacio en blanco o BOM y Salida de depuración como causas equivalentes. Los bytes invisibles antes de la etiqueta de apertura PHP se envían inmediatamente. En cambio, var_dump, echo o print_r permanece en el código de producción. Para distinguirlas, usa estas dos comprobaciones: Captura el mensaje completo, incluyendo el archivo y la línea “salida start at”; y inspecciona el archivo en un editor hex-aware para un BOM o espacio en blanco antes de <?php. Con esos datos podrás decidir si conviene aplicar la primera acción controlada —Quitar solo la salida no deseada y mantener los archivos solo PHP sin una etiqueta de cierre— o si debes conservar el estado actual y ampliar la investigación.
En un sitio de WordPress en producción, repite la petición que falla mientras compruebas una página que funciona correctamente y el área de administración. Un fallo aislado en una ruta requiere un rollback más acotado que un problema que afecta a PHP, la base de datos o todas las peticiones. Documenta la fecha y hora exactas, la URL o transacción afectada, el último estado correcto conocido y cada cambio realizado durante el diagnóstico. Ese registro permite distinguir una reparación reproducible de una desaparición temporal del síntoma.
Qué no debes hacer
No silenciar la advertencia sin eliminar la primera salida. Cookies y redireccionamientos pueden permanecer poco fiables incluso cuando los visitantes ya no ven el mensaje.
Cómo verificar la reparación
- Inicie sesión y redirija el trabajo sin advertencias.
- Los encabezados de la respuesta se envían antes del cuerpo.
- PHP logs no contiene nuevos errores de salida o visualización temprana.
Que el síntoma visible desaparezca no es suficiente. Cierra la incidencia solo cuando la acción original que fallaba, el recorrido de negocio relacionado y los registros relevantes confirmen que el problema ha desaparecido.