How to fix a blank WordPress profile page and an 11-million-row 404 log table

Complex WordPress sites can hide serious performance and security problems inside custom theme code. In one technical audit, a high-complexity data platform had two especially urgent issues: a Profiles page that returned HTTP 200 with an empty body, and a custom 404 tracking table that had grown to more than 11.5 million rows.

Freshy traced the blank profile output to debug file writes inside the custom theme and found that every 404 and redirect was being inserted into a dedicated database table. On staging, Freshy removed the failing debug writes, stopped the custom 404 logging, backed up and removed the oversized tracking table, hardened several custom admin actions, sanitized an unsafe query parameter, and disabled WP File Manager. The work was completed as staging remediation during a larger migration project; the source task does not document a production deployment.

Issue background

The WordPress site functioned more like a custom application than a typical brochure site. It included economic indicators, geographic profiles, comparisons, reports, data tables, contact forms, subscriptions, custom APIs, and several custom administrative tools.

During a technical audit, Freshy identified several urgent problems in the custom theme and supporting plugins.

The most visible issue affected the Profiles flow. A profile URL returned HTTP 200 after a few seconds but rendered a completely empty document.

The largest database issue was a custom table named:

wp_404_tracking

The theme inserted every 404 and redirect into that table. By the time of the audit, the table contained more than 10 million rows and consumed roughly 1 GB of database storage.

The audit also identified custom AJAX and admin actions that lacked sufficient capability checks, nonces, validation, or rate limiting, along with a raw query parameter being printed into HTML without proper escaping.

Diagnosis

The Profiles page was failing during custom file writes.

The custom Profiles template attempted to write debug files such as:

response.json
data.json

using relative file paths.

In the hosting environment, those paths resolved against a read-only shared WordPress core location. The file open failed, and the subsequent fwrite() call received an invalid handle. Under PHP 8.3, that produced a fatal condition and left the visitor with a zero-byte response.

Copies of the debug JSON files were also publicly reachable from the site root, making the debug behavior both a reliability and data-exposure concern.

The 404 logger had no practical upper bound.

The custom theme wrote every 404 and redirect event into wp_404_tracking. The original audit measured approximately 10.85 million rows and about 1.07 GB of data.

By the time Freshy performed the staging cleanup, the verified backup contained 11,517,438 rows.

The table had also been designed with only the numeric ID indexed, so it was not just large; it was poorly structured for long-term operational logging.

Several custom administration paths needed hardening.

The audit found an unauthenticated cache-regeneration AJAX action capable of triggering expensive API/cache work, cache deletion without a sufficient capability/nonce model, and a Geography Importer that could perform bulk database changes without CSRF protection.

The theme also printed:

$_GET['selected']

into an HTML attribute without proper escaping, creating a likely reflected-XSS pattern.

Resolution steps

The documented staging remediation included:

1. Fix the blank Profiles page. Freshy removed the debug file-write code that was causing the fatal behavior in the Profiles template.
2. Confirm the page rendered again. After the debug code was removed, the Profiles page returned HTTP 200 and displayed content normally on staging.
3. Stop the custom 404 logging first. Freshy disabled the theme logic that inserted every 404 and redirect into wp_404_tracking.
4. Verify that new 404s no longer created rows. The logging change was tested before any destructive database cleanup.
5. Back up the full 404 history. Freshy exported and integrity-checked all 11,517,438 rows before removing the table from staging.
6. Drop the oversized tracking table after verification. Once the backup was confirmed, the 404 table was removed so it could no longer bloat the staging database.
7. Harden the custom cache manager. Capability checks, nonces, validation, and per-user rate limits were added to reduce the risk of unauthenticated or abusive cache operations.
8. Harden the Geography Importer. The same security pattern was applied to the custom bulk-import workflow.
9. Sanitize and escape the selected query parameter. The unsafe raw output pattern was corrected.
10. Disable WP File Manager. Because the host already provided SFTP access, the plugin was disabled rather than leaving a high-risk file-management surface active.
11. Create a redacted service and license inventory. Freshy documented the site’s major integrations and ownership dependencies for migration planning.

An administrator-access cleanup was also tested, but that change was explicitly reverted while the team waited for client approval. The public article therefore does not treat administrator reduction as a completed remediation item.

The broader audit also recommended future work such as API timeouts, safer retries, improved cache/error handling, Highcharts accessibility support, plugin updates, dashboard-link repairs, and additional migration documentation. Those items were not all completed in this task.

Final outcome

The staging environment was left in a substantially safer and cleaner state.

The verified outcomes were:

• The previously blank Profiles page rendered correctly again.
• The custom theme stopped inserting every 404 and redirect into the database.
• More than 11.5 million historical tracking rows were backed up and the oversized table was removed from staging.
• The custom cache manager and Geography Importer received stronger capability, nonce, validation, and rate-limit protections.
• The unsafe selected query parameter handling was corrected.
• WP File Manager was disabled.

The task later became part of a wider migration and redesign discussion. The source history does not explicitly document these staging remediations being deployed to production, so this article does not claim a live rollout.

The broader lesson is that custom WordPress code can quietly accumulate application-level technical debt that plugins alone will not reveal. Debug writes, unbounded logging tables, custom AJAX endpoints, and one-off importer tools all need the same maintenance discipline as production application code.

If your WordPress site has a custom theme, large bespoke data flows, unexpected database growth, or blank pages that do not produce obvious errors, contact Freshy. Our WordPress team can audit the custom code, identify the true failure path, and remediate high-risk behavior safely on staging before a production rollout.