Last week a Google Search Console alert told us 2,246 pages on our site were returning 5xx errors. That number was surprising on its own. What made it worse was what those error pages had been showing to anyone who loaded them.
APP_DEBUG was set to true in production.
If you've worked with Laravel you already know what that means. For everyone else: instead of a generic "something went wrong" page, every crashing route was rendering Laravel's full debug screen. File paths. Stack traces. The actual source code around the failing line. SQL queries with table and column names. On some pages, environment variables.
Publicly. For months. Indexed by Google.
Here's how we found it, what the actual damage was, and the checklist we now run before anything goes live.
How it surfaced
We weren't looking for this. We were doing a routine SEO audit and pulled the Page Indexing report in Search Console.
The breakdown looked like this:
Top comments (1)
Search Console is the copy you can clean. The ones you can't are Bing's index, Wayback snapshots, and Common Crawl, which is where GPTBot and CCBot got their corpus for months while those pages were live. So the 410s are the easy half; a stack trace with real table and column names is now sitting in archives nobody can request removal from, which makes credential rotation the more urgent line item. I'd also add a check for what a non-Google crawler sees on the domain, since that's the part no report shows you. We built a free check for that in Viewfy, but curl with a GPTBot user agent gets you most of it.