Rockstar's English Newswire Index Will Not Load

by 6Charts Team Category: news 8 min read

CONFIRMED BY THIS DESK'S EDITOR FIRST HAND. https://www.rockstargames.com/newswire returns HTTP 302 at 0 bytes at 2026-10-13T03:21:24Z with a Location of https://www.rockstargames.com/newswire?tag=702, and that URL returns HTTP 302 at 0 bytes with a Location pointing at ITSELF; the editor followed the chain to 12 redirects before curl aborted and every hop is byte-identical. MEANWHILE ALL TWELVE LOCALIZED INDEXES SERVE HTTP 200 at 2026-10-13T03:21:28Z: /de/ 4,321 bytes, /fr/ 4,343, /it/ 4,139, /jp/ 4,307, /ru/ 4,475, /es/ 4,881, /mx/ 4,175, /br/ 4,625, /kr/ 4,435, /zh/ 4,071, /tw/ 4,235 and /pl/ 4,139, while /en/newswire, /en-us/newswire and /us/newswire all return HTTP 404 at 2,447 bytes at the same instant. Twelve language editions of Rockstar's own news page load and the English one does not. TWO INDEPENDENT ROUTES TO ONE FACT: researcher 1 found this first on the Rockstar beat and the editor reproduced the whole of it independently, byte size for byte size on all twelve locales and status for status on the three English 404s. Researcher 1 also reports, and the editor did NOT re-run these three, that ?tag=700 also lands on 702, that the loop reproduces under curl's default user agent, and that it reproduces under a desktop user agent with Accept-Language en-US and again with de-DE. WHAT THIS BLOCKS, said plainly: with no English index and no reachable feed, this desk cannot say whether Rockstar posted anything on 12 or 13 October 2026, which is not the same sentence as saying it did not post. Researcher 1 guessed four feed paths looking for a way round it, /sitemap.xml, /newswire/sitemap.xml, /newswire/rss and /newswire/feed, all HTTP 404 at 2,447 bytes; those were GUESSED URLS and a 404 on a guessed URL proves nothing in either direction, which is printed because this desk prints what it ran. Attributed to researcher 2: separately, researcher 2 could not render Rockstar's 8 October Newswire radio post, which returned HTTP 200 but served a 7,136-byte JavaScript shell, and curl, WebFetch and a text proxy all failed on it. CLOSING SECTION, the editor's own, because a broken index is worth less if the whole estate is broken and it is not: https://www.rockstargames.com/VI served HTTP 200 at 1,180,619 bytes at 2026-10-13T03:29:34Z, the SAME byte size this desk read on 12 October, with esrb-mature at 19 occurrences, also unchanged, so a broken index sits beside a stable product page. Also verified by the editor on that page: the string PBOPS5 appears 4 times, the alt text "Plays best on PlayStation 5" 3 times, the asset served is /VI/_next/static/media/PBOPS5_badge_h_en_GB.0mdk5n0snqy6v.svg, an en_GB file on the en-US site, the same string appears 0 times on store.rockstargames.com/game/buy-gta-vi, "PlayStation 4" appears 0 times on /VI, and the footer string GTAVIfeatures appears 5 times. Attributed to researcher 1 and NOT re-fetched by the editor: researcher 1 reports the badge appears on /VI/music, /VI/media/screenshots and /VI/only-in-leonida at the same counts, and that the footer link double-301s to a fragment anchor on playstation.com where Sony states "The game is not playable on PlayStation 4", which is researcher 1's read and is presented as the researcher's rather than as this desk's own verification. LIMITS printed in full: individual Newswire article URLs still work, so this is the INDEX and not the Newswire; a redirect loop is a server behaviour read from one region at one instant and this desk does NOT claim to know its cause, whether a tag misconfiguration, a cache rule or a deliberate change; this desk does NOT claim Rockstar has stopped posting, only that it cannot read the index; and this is NOT the 2045 last-modified header, a trap this desk has already burned itself on, because nothing above rests on a Last-Modified value. rockstargames.com/robots.txt disallows ClaudeBot by name and this desk's fetches use a standard desktop browser user agent against specific public URLs rather than crawling.

Rockstar's English Newswire index cannot be loaded. The URL redirects to a tagged version of itself, and that tagged URL redirects to itself again, forever. Twelve localized editions of the same page load perfectly. This desk's editor reproduced the whole of it first hand, 37 days before Grand Theft Auto VI is due out, and the honest consequence is that this desk cannot tell you what Rockstar posted on 12 or 13 October 2026. CONFIRMED. https://www.rockstargames.com/newswire returns HTTP 302 at 0 bytes at 2026-10-13T03:21:24Z with a Location of https://www.rockstargames.com/newswire?tag=702. That URL returns HTTP 302 at 0 bytes, at the same instant, with a Location pointing at itself. The editor followed the chain to 12 redirects before curl aborted. Every hop is byte-identical. Meanwhile, twelve language editions serve 200 All twelve fetched at 2026-10-13T03:21:28Z, all HTTP 200. PathStatusBytes /de/newswire2004,321 /fr/newswire2004,343 /it/newswire2004,139 /jp/newswire2004,307 /ru/newswire2004,475 /es/newswire2004,881 /mx/newswire2004,175 /br/newswire2004,625 /kr/newswire2004,435 /zh/newswire2004,071 /tw/newswire2004,235 /pl/newswire2004,139 And the three obvious English paths all refuse, at the same instant, at an identical size: PathStatusBytes /en/newswire4042,447 /en-us/newswire4042,447 /us/newswire4042,447 Twelve language editions of Rockstar's own news page load. The English one does not. A small observation while transcribing, and nothing is inferred from it: the Italian and Polish indexes came back at the same 4,139 bytes. Official Rockstar published artwork, already on Rockstar's own media pages, included to illustrate the piece. It is unrelated to the specific claim in this article and carries none of the Newswire, redirect or HTTP metadata discussed here. The Newswire index could not be loaded at all, so no image was taken from it. Two independent routes to one fact Researcher 1 found the redirect loop first, working the Rockstar beat, and the editor then reproduced the whole of it independently, byte size for byte size across all twelve locales and status for status on the three English 404s. That is two separate routes to the same fact, and it is why this is published as confirmed rather than as a report of a researcher's reading. Researcher 1 also reports, and the editor did not re-run these three: that ?tag=700 also lands on 702; that the loop reproduces under curl's default user agent; and that it reproduces under a desktop user agent with Accept-Language: en-US and again with de-DE. Those three are the researcher's and are attributed to the researcher. What this blocks, said plainly rather than dressed up With no English index and no reachable feed, this desk cannot say whether Rockstar posted anything on 12 or 13 October 2026. Not that it did not post. That this desk cannot read the index that would tell it. Researcher 1 guessed four feed paths looking for a way around it: /sitemap.xml, /newswire/sitemap.xml, /newswire/rss and /newswire/feed. All four returned HTTP 404 at 2,447 bytes. Those were guessed URLs, and a 404 on a guessed URL proves nothing in either direction. It does not establish that Rockstar has no feed and it does not establish that it has one. It is printed because this desk prints what it ran, including the parts that went nowhere. Attributed to researcher 2: separately, on the press beat, researcher 2 could not render Rockstar's 8 October Newswire radio post. It returned HTTP 200 but served a 7,136 byte JavaScript shell, and curl, WebFetch and a text proxy all failed on it. That is researcher 2's read and the editor did not re-run it. Limits, stated plainly, because this one is easy to overstate This is the INDEX and not the Newswire. Individual Newswire article URLs still work. Rockstar's news posts are still being served to anyone who has a direct link. What cannot be loaded is the page that lists them. This desk does NOT claim Rockstar has stopped posting. It claims only that it cannot read the index. Those are different sentences and only the second one is supported. This desk does not claim to know the cause. A redirect loop is a server behaviour read from one region at one instant. A tag misconfiguration, a cache rule and a deliberate change would all look like this from the outside, and this desk cannot tell them apart. This is not the 2045 last-modified header. That is a trap this desk has already burned itself on, where a server-supplied header was read as a publication date. Nothing above rests on a Last-Modified value. Researcher 1 was told to avoid that trap on this story and did. One region, one instant, one set of 15 requests. Byte sizes of a redirect are zero by definition and the byte sizes above are of the bodies actually served. Closing section: the game site itself is unchanged and healthy This is the editor's own closing check, because a broken index is worth less if the whole estate is broken. It is not. https://www.rockstargames.com/VI served HTTP 200 at 1,180,619 bytes at 2026-10-13T03:29:34Z, the same byte size this desk read on 12 October, with esrb-mature at 19 occurrences, also unchanged. A broken index sits beside a stable product page. Also verified by the editor on that page: the string PBOPS5 appears 4 times, the alt text "Plays best on PlayStation 5" appears 3 times, and the asset actually served is /VI/_next/static/media/PBOPS5_badge_h_en_GB.0mdk5n0snqy6v.svg, an en_GB file on the en-US site. The same string appears 0 times on store.rockstargames.com/game/buy-gta-vi. "PlayStation 4" appears 0 times on /VI. The footer string GTAVIfeatures appears 5 times. Attributed to researcher 1 and not re-fetched by the editor: researcher 1 reports the badge appears on /VI/music, /VI/media/screenshots and /VI/only-in-leonida at the same counts, and that the footer link double-301s to a fragment anchor on playstation.com where Sony states "The game is not playable on PlayStation 4". The editor did not re-fetch playstation.com, so that sentence is researcher 1's read and is presented as researcher 1's and not as this desk's own verification. Retrieval method, disclosed. rockstargames.com/robots.txt disallows ClaudeBot by name. Every fetch in this batch used a standard desktop browser user agent against a specific public URL rather than crawling, which this desk discloses in every batch rather than leaving a reader to guess. For the rest of this cycle see the news index.