What matters first: The warning contains two locations: where output began and where WordPress later attempted to send a header. Repair the first location, not the downstream cookie or redirect call.
What this symptom actually tells you
Whitespace, a UTF-8 BOM, debug echo, warning or accidental HTML can start output early. The visible symptom may be login failure, broken redirects, feed errors or an exposed warning.
Capture evidence before changing anything
- Capture the full message, including “output started at” file and line.
- Inspect the file in a hex-aware editor for a BOM or whitespace before <?php.
- Check logs for an earlier warning that printed before the header operation.
- Compare the file with its clean version or version-control history.
Most common causes
- Whitespace or BOM: Invisible bytes before the PHP opening tag are sent immediately.
- Debug output: var_dump, echo or print_r remains in production code.
- Earlier warning: A notice or deprecation is displayed and becomes the first output.
- Closing PHP tag: Whitespace after ?> in a PHP-only file can leak into the response.
Safe diagnostic and repair sequence
- Remove only the unintended output and keep PHP-only files without a closing tag.
- Disable display_errors in production while retaining protected logging.
- Restore the clean plugin, theme or core file when modification is unexplained.
- Test the action that needs headers: login, redirect, cookie or feed response.
How to choose between the likely causes
Do not treat Whitespace or BOM and Debug output as interchangeable. Invisible bytes before the PHP opening tag are sent immediately. By contrast, var_dump, echo or print_r remains in production code. Use two checks to separate them: Capture the full message, including “output started at” file and line; and inspect the file in a hex-aware editor for a BOM or whitespace before <?php. Those observations usually show whether the next safe move is to remove only the unintended output and keep PHP-only files without a closing tag or to preserve the current state and widen the investigation.
On a production WordPress site, repeat the failing request while checking a known-good page and the admin area. A fault isolated to one route calls for a narrower rollback than a failure affecting PHP, the database or every request. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not silence the warning without removing the first output. Cookies and redirects can remain unreliable even when visitors no longer see the message.
How to verify the repair
- Login and redirects work without warnings.
- Response headers are sent before the body.
- PHP logs contain no new early-output or display errors.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
WP REPAIR INCIDENT STANDARD
Safe intervention sequence
Whitespace, a UTF-8 BOM, debug echo, warning or accidental HTML can start output early. The visible symptom may be login failure, broken redirects, feed errors or an exposed warning.
- Capture the full message, including “output started at” file and line.
- Inspect the file in a hex-aware editor for a BOM or whitespace before <?php.
- Check logs for an earlier warning that printed before the header operation.
- Compare the file with its clean version or version-control history.
What must be verified
- Login and redirects work without warnings.
- Response headers are sent before the body.
- PHP logs contain no new early-output or display errors.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Should I fix the location where the header call failed, or the location where output started?+
Fix the first-output location, not the downstream header call. The warning names two places — where output began and where WordPress later tried to send a header — and the root cause is always at the earlier one.
Does simply turning off display_errors make this problem actually go away?+
No. Disabling display_errors only hides the visible warning; it does not remove the unintended output that is interfering with cookies and redirects. Login, redirects, and other header-dependent features can remain unreliable even after the message stops appearing.
Can a file with no visible extra code still cause this error?+
Yes. A UTF-8 BOM or stray whitespace before the opening <?php tag, or trailing whitespace after a closing ?> tag, is invisible in most editors but gets sent as output immediately. Inspecting the file in a hex-aware editor is often necessary to catch this.
How is this different from a plugin update simply breaking a feature?+
This specific error is about output timing, not broken logic — the plugin or theme code may otherwise work correctly, but something is echoing or leaking text before WordPress attempts to send headers. Checking logs for an earlier notice or deprecation warning that printed first often reveals the real trigger.