economist: article pages now behind a Cloudflare challenge, full-text routes cannot work
- Dominant language
- TypeScript
- Stars
- 46.2k
- Forks
- 10.2k
- Avg merge
- 8h 48m
- Merged PRs (30d)
- 175
Description
### Routes
```routes
/economist/espresso
/economist/:endpoint
/economist/global-business-review/:language?
```
### Full routes
```fullroutes
/economist/espresso
/economist/latest
```
### Related documentation
https://docs.rsshub.app/routes/economist
### What is expected?
The route returns the category feed with full article text.
### What is actually happening?
HTTP 503, e.g.
```
FetchError: [GET] "https://www.economist.com/1843/2026/08/21/the-kremlins-crypto-king": 403
```
economist.com now serves a Cloudflare managed challenge on article pages. The 403 body is the `Just a moment...` interstitial rather than a plain denial.
This is not specific to one article, and not to `/interactive/` URLs. Every article page I tried returns 403, with and without a browser User-Agent, and through the route's own `got` client including its retries. The route uses `Promise.all` over the articles, so the error names whichever one rejected first, which makes it look article-specific when it is not.
The feeds themselves are NOT blocked, only the article pages:
```
FEED https://www.economist.com/1843/rss.xml 200 (no UA override), 200 (browser UA)
ARTICLE https://www.economist.com/1843/2026/08/21/... 403 (no UA override), 403 (browser UA)
```
I think this leaves the route dead rather than broken:
- the only thing `/economist/:endpoint` adds over the publisher's own feed is full article text, plus categories scraped from the article's ld+json. Both come from the article page, and both are now behind the challenge.
- the publisher's feed already works in any reader without RSSHub. Each item carries `title`, `link`, `guid`, `pubDate` and an ~86 character `description`, with no `content:encoded` and no `category`. Presumably it has always been that way, given the paywall.
- so making the route fall back to the RSS description would emit a feed equivalent to subscribing to `https://www.economist.com//rss.xml` directly. It would stop the 503 without leaving anyone a reason to use the route.
Possibly relevant for the docs either way. The `endpoint` parameter description points at https://www.economist.com/rss as the place to find valid endpoints, but that URL now redirects to the podcasts page, so it no longer lists endpoints for feeds at all.
I don't know if there's a way to mark a route as obsolete/deprecated or it should just be removed.
For anyone landing here because their feed broke, the publisher's own feeds still work unauthenticated and can be used directly in a reader. The broadest ones:
```
https://www.economist.com/latest/rss.xml 301 items, spanning 23 sections
https://www.economist.com/printedition/rss.xml 44 items, spanning 17 sections
https://www.economist.com/the-world-this-week/rss.xml 301 items, the weekly round-up
```
`latest` is effectively a whole-site feed and is the closest single replacement for the route. Per-section feeds follow the same `https://www.economist.com//rss.xml` pattern; I confirmed at least 39 working endpoints by probing, and that is not exhaustive, since there's no index to work from.
### Deployment information
Self-hosted
### Deployment information (for self-hosted)
Docker, current master
### Additional info
```shell
[error]: https:///economist/1843: "HTTP 503"
Reproduced locally on master (40aca9548e).
```
### This is not a duplicated issue
- [x] I have searched [existing issues](https://github.com/DIYgod/RSSHub/issues) to ensure this bug has not already been reported
Contributor guide
Research direction
Start with the /economist/:endpoint and full routes, then read the related Economist route documentation. Confirm the feed-versus-article behavior and the Promise.all failure described in the issue; completion depends on deciding and documenting whether the route should be removed, deprecated, or otherwise replaced, with the route no longer returning the reported 503.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- api, backend
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100