“Warning: Cannot modify header information - headers already sent in /wp-includes/pluggable.php on line 1435”
PHP has to send a page's headers (redirects, cookies, content type) before any of its content. Some file printed output too early, even a single blank line or space, so when WordPress later tried to redirect or set a cookie, it was too late. The warning names two places: "output started at" is the file that printed too early, which is the culprit; "in ... pluggable.php" is only where WordPress noticed. On a live site the warning often comes with a login that loops or a redirect that doesn't happen.
Is your site showing it right now?
The free scan loads your page like a visitor and checks for this message, plus broken links, script errors and phone layout. It also walks your signup, booking or contact form, without sending anything.
Free, no signup. Usually done in about a minute.Why it happens
- A blank line or space before <?php, or after a closing ?> tag, at the end of functions.php, wp-config.php or a plugin file (the commonest cause after editing a file by hand)
- A plugin or theme that echoes text or an error message during loading, before the page starts
- A file saved with a UTF-8 byte order mark (BOM), which browsers don't show but PHP sends as output
- A PHP warning or notice printed by other code (with display_errors on), which itself counts as output
- A theme's functions.php that prints HTML outside of a hook
How to fix it
Read the "output started at" part
That file and line is where the stray output came from. The "in" file (pluggable.php) is innocent; don't edit WordPress core. If the warning doesn't show it, turn on WP_DEBUG briefly or read the PHP error log.
Remove whitespace around the PHP tags
Open the named file in a plain code editor. Delete anything before the opening <?php, and delete the closing ?> at the end of the file entirely (PHP doesn't need it, and a newline after it is exactly this bug).
Save without a BOM
In your editor, set the encoding to "UTF-8 without BOM" (or "UTF-8", not "UTF-8 with signature") and save again. Notepad and some FTP clients add the BOM silently.
Still there? Find the plugin
Deactivate plugins one at a time (or rename the plugins folder over SFTP if you can't log in), reload, and see which one stops the warning. Switch to a default theme to rule out the theme. Report it to the plugin's author or replace the plugin.
Hide warnings from visitors
Once fixed, make sure display_errors is off on the live site (WP_DEBUG false, WP_DEBUG_DISPLAY false) and errors go to the log. Visitors should never see PHP warnings, and a visible warning can itself break redirects.
Questions
Why can't I log in to WordPress?
The login works by sending a cookie and a redirect in the headers. With output already sent, both fail, so you land back on the login form. Fix the stray output (often over SFTP) and the login comes back.
Is it safe to delete the closing ?> tag?
Yes. In a file that's all PHP, the closing tag is optional and WordPress's own coding standard says to leave it out, precisely to avoid this warning.
The warning names a plugin I need.
Check for an update first; this is a common bug that authors fix. If it persists, tell the author the file and line from "output started at", and use a different plugin until it's fixed.
Can Page Canary tell me if this comes back?
Yes. Page Canary checks your key pages every day for this message and others like it, confirms it on a second check, and emails you with the fix. One site is free.