My Site Hit an All-Time High in Google Rankings. Then I Discovered 30,000 Pages Are Completely Broken.

StockVS is a multilingual stock data platform — 8,000+ US tickers, 2,500 ETFs, 12 languages. Last week was the best week yet:

• 2,425 pages indexed by Google — all-time high, up 31% in one week

• 28-day average position dropped from 52 to 27.7 — rankings accelerating fast

• 39 queries now in Google's top 10, up from 12 two weeks ago

• Bing at 11,600 indexed pages, Yandex at 15,333 — both growing steadily

I was feeling great. Then I ran a routine page audit on the Canadian stock pages I added three weeks ago (2,500 TSX tickers like RY.TO and BNS.TO).

Every. Single. One. Returns an AccessDenied XML error from Digital Ocean Spaces.

That's roughly 30,000 pages (2,500 tickers × 12 languages) serving error pages instead of HTML. Google has been crawling these URLs and getting errors for weeks — which could be poisoning the quality signals for the entire domain, including the US pages that are actually ranking.

The likely cause: the .to suffix in TSX ticker symbols causes path resolution issues in static file hosting. When Astro builds the page at /en/stock/ry.to/index.html, Digital Ocean Spaces chokes on the .to in the path — possibly interpreting it as a domain extension rather than a file path.

The irony? The massive spike in Google's "discovered but not indexed" bucket (from 25K to 73K pages) that I attributed to Google just being slow... was probably Google discovering 50,000 broken pages and rightfully refusing to index them.

The US pages are fine — check the AAPL analysis at https://stockvs.com/en/stock/aapl or the SPY ETF page at https://stockvs.com/en/etf/spy to see what a healthy page looks like.

What I'm doing about it:

1. Filed as P1/Urgent in Linear (DEV-94)

2. Investigating URL encoding or path rewriting to fix .to resolution

3. May need to restructure TSX URLs entirely (e.g., /en/stock/ry-to instead of /en/stock/ry.to)

This is a reminder that adding a new market to a programmatic site isn't just "run the same pipeline with new tickers." Edge cases in URL structures can break at the hosting layer in ways you'd never catch without auditing.

Has anyone else hit hosting issues with special characters (dots, hashes, etc.) in URL paths on S3-compatible storage? Curious if this is a known DO Spaces gotcha or if I need to rethink my URL scheme entirely.