What the headers already sent warning means
HTTP headers have to be sent before the body of a web page. WordPress uses headers for actions such as redirects, cookies and response status information.
If PHP has already sent visible output, whitespace or an error message to the browser, a later attempt to change those headers can trigger a warning such as Warning: Cannot modify header information - headers already sent by.
The most useful part of the message is often the text after output started at. That file and line indicate where PHP believes the first output occurred. The later file mentioned after headers already sent by may simply be the WordPress function that discovered the problem, so editing that second file can send troubleshooting in the wrong direction.
Common causes of headers already sent in WordPress
A recent manual edit is a common starting point. In wp-config.php, a plugin file or a theme file, even unintended output before WordPress sends its headers can cause the warning.
- Whitespace or characters before the opening <?php tag.
- Whitespace or other output after a closing PHP tag in a PHP-only file. Many PHP-only files deliberately omit the closing tag to reduce this risk.
- An echo, print, var_dump() or debugging statement left in production code.
- A PHP warning or notice being displayed before a redirect or cookie is set.
- A plugin or theme update containing faulty code, or custom code added to functions.php or another included file.
- A file saved with an unexpected byte order mark or other invisible characters before the PHP opening tag.
Do not assume the problem is WordPress core simply because the second path in the warning points into wp-admin or wp-includes. The earlier output location is normally the better place to start.
How to fix headers already sent safely
Take a full backup of the website files and database before editing files. If possible, reproduce and correct the fault on a staging copy first.
- Copy the complete warning and identify the file and line following output started at. Check what changed there recently.
- If the path points to wp-config.php or a custom PHP file, inspect the beginning of the file for spaces, blank lines or unexpected characters before <?php. Also inspect the end of PHP-only files for output after a closing tag.
- Remove temporary output such as echo, print or var_dump() that runs before WordPress sends redirects or cookies.
- If the path belongs to a plugin or theme and the problem appeared after an update, update to a known compatible release or restore the previous working version from a proper backup. If wp-admin is inaccessible, a specific plugin can be disabled by renaming its directory under wp-content/plugins.
- If the warning is caused by another PHP warning being printed first, log errors rather than displaying them publicly while diagnosing. WordPress documents the following approach in wp-config.php:
Remove or disable debugging when the investigation is complete and protect or remove any debug log that contains sensitive paths or data.define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false); @ini_set('display_errors', 0); - Do not treat PHP output buffering as the first fix. Buffering can delay output, but it may hide the original defect rather than correcting the file that sent output too early.
Do not edit WordPress core files to suppress the warning. A core update could overwrite the change, and the real cause is usually elsewhere.
When to get help with a headers already sent error
Stop if the reported file is unfamiliar custom code, the error returns after every update, or several plugins appear in the call sequence and you cannot determine which one actually produced the first output. The same applies if the warning is only visible during checkout, login or form submission, where hiding the message without testing the affected action can leave a functional problem in place.
If you have already restored the last changed file and the warning remains, check server and WordPress logs rather than making unrelated edits.
Web Support Services provides an Emergency Fix for £249 per incident with a response within 2 working hours. Care plans start from £59 a month for ongoing website maintenance and support.