fix(proxy): hardcode INDEXABLE_HOSTS, decouple from NEXT_PUBLIC_SITE_URL#48
Conversation
Staging deploy after PR #47 still wasn't getting noindex'd. Root cause: PR #42 derived the indexable host set from NEXT_PUBLIC_SITE_URL. PR #43 set NEXT_PUBLIC_SITE_URL_STAGING for the staging build (so client-side share buttons / canonical URLs use the staging URL). On staging that meant proxy.ts computed PRODUCTION_HOSTS = {staging.catholicdigitalcommons.org, www.staging…} — and treated staging as indexable. Exactly the opposite of intent. Two different concepts were conflated: - NEXT_PUBLIC_SITE_URL = "what URL THIS deployment thinks it is" (different per environment) - INDEXABLE_HOSTS = "what URLs search engines should index" (always production, regardless of build) Fix: hardcode INDEXABLE_HOSTS in proxy.ts. The production hostname is stable; if it ever changes, a code change is appropriate. Removing the env-derived path eliminates the class of bug entirely. NEXT_PUBLIC_SITE_URL stays per-environment so share-buttons, sitemap canonicals, and other content-side absolute URLs continue to point to the right place per build. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Warning Rate limit exceeded
To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Review rate limit: 0/1 reviews remaining, refill in 48 minutes and 48 seconds.Comment |
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | -7 |
| Duplication | 0 |
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
Summary
After PR #47 fixed the prod-was-being-noindex'd bug, the staging
deploy still didn't get noindex'd. Verified after staging redeploy
(run 25193770888):
Root cause
PR #42 derived the indexable-host set from
NEXT_PUBLIC_SITE_URL.PR #43 + the build env work set
NEXT_PUBLIC_SITE_URL_STAGINGsothe staging build's share buttons and canonical URLs would point at
staging. But that meant
proxy.tson staging computed:…and treated the incoming staging host as indexable. The opposite
of intent.
Two distinct concepts were collapsed into one variable:
NEXT_PUBLIC_SITE_URLINDEXABLE_HOSTS)Fix
Hardcode
INDEXABLE_HOSTSinproxy.ts. No env override:If the canonical hostname ever changes, that's a code change.
Eliminates the env-derived bug class entirely.
NEXT_PUBLIC_SITE_URL_PROD/NEXT_PUBLIC_SITE_URL_STAGINGstilldiverge per environment — they drive content-side absolute URLs
(share buttons, sitemap canonicals) which DO need to be different.
Urgency
Staging is currently NOT noindex'd. Lower urgency than PR #47 (which
was fixing the inverse — production being noindex'd) but still
worth deploying soon to stop staging URLs being indexable.
Test plan
npm run buildclean locallychange expected; prod still NOT noindex'd) and Build and
Deploy to Staging (staging now noindex'd)
curl -I https://catholicdigitalcommons.org/→ noX-Robots-Tagcurl -I https://staging.catholicdigitalcommons.org/→X-Robots-Tag: noindex, nofollow🤖 Generated with Claude Code