Founding customers get 50% off the first year. Claim it →
← all posts

Which Google News RSS search operators work

October 26, 20268 min readFeedmarkdown#google-news#rss#search-operators

Most Google News search operators work inside the q parameter of the RSS search endpoint. A few do nothing, and the roughly 100-item cap on a feed matters more than any of them.

We tested this on 2026-10-22 with 49 requests: a 41-request matrix, then 8 more to check a claim in an earlier post. One query family, one IP, one day. URL formats and the hl/gl/ceid edition rules are in the Google News RSS feed guide, so we skip them. We did not test the website's Advanced search page, languages other than German, or how results change over a day.

Which Google News search operators work

The short version, from 38 variants:

Worked

  • when: with hour, day and year units (1h, 12h, 1d, 7d, 30d, 1y)
  • site:domain and -site:domain
  • -word
  • after: plus before: together
  • source:reuters
  • OR

Mostly worked

  • AND and a plain space: both terms showed up in 92 and 87 of 100 items. Close, not strict.

Partly worked, or we can't tell

  • "exact phrase": the phrase showed in 46 of 108 titles and snippets. Matching may run on article text we did not fetch, so we can't say it is ignored.
  • before: alone: 2 of 100 items were dated after the cutoff.
  • intitle:: inconclusive. 100 of 100 titles had the word, but plain tesla already gave 102 of 103.
  • inurl: (6 old items) and filetype:pdf (30 items, none with PDF titles): no sign they filter anything.
  • A path after site:, such as site:reuters.com/business: accepted, but we can't verify the path from the feed.

Did nothing, or returned nothing

  • site:a OR site:b: only the first site came back.
  • allintitle:: an empty feed.
  • when:1w: an invalid unit. HTTP 200, zero items.
  • when: combined with after:: when: won and after: was ignored.

Google does not document any of this for the RSS endpoint, so nothing here is promised to stay true.

Table of Google News RSS operators with a verdict of works, mostly, partly, unclear or no, and what each returned on 2026-10-22

How we tested

Each variant got one GET to https://news.google.com/rss/search?q=...&hl=en-US&gl=US&ceid=US:en, with a Mozilla/5.0 user agent. We waited 5 seconds between requests, made one attempt per variant, never retried, and would have stopped on a 429, a 403 or a redirect to a consent page. None appeared. The run took about 3 minutes 25 seconds from a home connection in the Netherlands, with no cookies, account or key.

The base query was electric vehicles, plus tesla and reuters.com for the others. The matrix script capped itself at 40 requests per run and sent 38. A follow-up sent 3 more (two repeats and one new date test), so 41. The 8 later requests are the site: check below.

We judged whether an operator was honoured from the <source> element (publisher), titles and snippets. The <link> is a news.google.com redirect, so we can't see publisher URLs. That is also why inurl: is hard to judge. The core of the script (the snippet leaves out the consent-redirect check):

import time, urllib.parse, urllib.request, urllib.error
import xml.etree.ElementTree as ET
from email.utils import parsedate_to_datetime

ED = "hl=en-US&gl=US&ceid=US:en"
QUERIES = ["electric vehicles", "electric vehicles when:1d",
           "site:reuters.com", "electric vehicles -site:reuters.com"]

class NoRedirect(urllib.request.HTTPRedirectHandler):
    def redirect_request(self, *args, **kwargs):
        return None  # record 302s instead of following them

opener = urllib.request.build_opener(NoRedirect)
for n, q in enumerate(QUERIES):
    if n:
        time.sleep(5)
    url = f"https://news.google.com/rss/search?q={urllib.parse.quote_plus(q)}&{ED}"
    req = urllib.request.Request(url, headers={"User-Agent": "Mozilla/5.0"})
    try:
        resp = opener.open(req, timeout=30)
        status, body = resp.status, resp.read()
    except urllib.error.HTTPError as e:
        status, body = e.code, b""
    if status in (429, 403):
        print("stop:", status)
        break
    items, dates, pubs = 0, [], set()
    if status == 200:
        for item in ET.fromstring(body).iter("item"):
            items += 1
            dates.append(parsedate_to_datetime(item.findtext("pubDate")))
            pubs.add(item.findtext("source"))
    span = f"{min(dates):%Y-%m-%d} to {max(dates):%Y-%m-%d}" if dates else "-"
    print(f"{q:<40} {status} items={items} {span} publishers={len(pubs)}")

Add your own variants to QUERIES. Our full matrix had 38 rows, with a per-operator check on top. Trimmed output from our run:

Terminal output listing HTTP status, item count, oldest to newest date and publisher count for 12 Google News RSS query variants on 2026-10-22

Limits: counts cap at about 100, so "100" means "at least". Each variant ran once, except two repeats, so we know nothing about variance. Counts move between runs: our pick-sources post saw 59 items, then 80 two minutes later. pubDate is Google's date, not always the publish date.

when: and the 100-item cap

Every window except 1h returned exactly 100 items. Full searches without a window returned 102, 103, 106 and 108, so we say "about 100".

Window Items Oldest item
when:1h 36 about 1 hour old
when:12h 100 11 hours
when:1d 100 21 hours
when:7d 100 167 hours
when:30d 100 2026-09-23
when:1y 100 2025-10-24

Bar chart of the oldest item age for each when: window from 1 hour to 1 year, with 36 items for 1 hour and 100 items for every other window

A wider window gives about 100 items from a longer span, not everything in it, and not strictly the newest 100: when:30d stopped a day short of now. when:1h returned 36, which may only mean 36 existed. Pick the narrowest window you need and poll often. For polling limits, see scraping Google News: rate limits and redirects.

We tested h, d and y only. We did not test m or minutes.

Failures come in two shapes. when:1w returned HTTP 200 and an empty feed. An empty q= returned a 404. If you monitor a feed, check for zero items, not only the status code.

site: and -site:

site:reuters.com returned 100 items, all labelled Reuters. electric vehicles -site:reuters.com returned 100 items from 57 publishers, none Reuters. source:reuters also worked: 34 of 34 items were Reuters, though only 34 came back and some were old.

Combining two sites did not work. site:reuters.com OR site:bbc.com returned 100 Reuters items and no BBC. For several outlets, run one feed per site. Picking sources for a niche digest does that.

Editions change the result. site:spiegel.de in the German edition returned 100 items labelled Spiegel, dated 2026-10-21 to 2026-10-22. In the US edition it returned a different, older set: 81 labelled Spiegel and 19 with other spiegel.de labels such as SPIEGEL Shop, with the oldest item dated 2005-05. See the editions section of the feed guide.

Do terms narrow a site: feed?

Our pick-sources post found that adding offshore wind to site: changed nothing for four outlets. On reuters.com we saw the opposite: site:reuters.com gave 100 items spanning about 15 hours, and electric vehicles site:reuters.com gave 100 items spanning 18 days. So the term changed the set.

We re-ran that post's exact queries on 2026-10-22, site:<domain> offshore wind when:8d and site:<domain> when:8d: 8 requests, 5 seconds apart.

Outlet With terms Site only Same items? Wind or offshore in headline (terms / site only)
canarymedia.com 32 32 yes 3 / 3
rechargenews.com 27 28 no, 3 and 4 items unique 20 / 22
windpowermonthly.com 35 35 no, 1 and 1 unique 35 / 35
power-technology.com 27 27 no, 1 and 1 unique 8 / 7

The terms did not narrow these four outlets on 2026-10-22: counts match within 1, and the items overlap almost completely. They did for reuters.com. We offer no cause. The counts are higher than in the earlier post (25, 25, 29 and 20) and the window now covers different days. Counts move, and one run per query can't separate a day effect from noise.

Exact phrases, OR, AND and minus

  • "electric vehicles" returned 108 items. The phrase appeared in 46 of them, in the title or snippet.
  • tesla OR rivian returned items with both terms: tesla in 93 of 100 and rivian in 16. The skew may just be news volume, since we had no control.
  • tesla AND rivian had both terms in 92 of 100. Plain tesla rivian had both in 87.
  • tesla -musk had musk in 0 of 100 items. Plain tesla had it in 33 of 103.

Media monitoring on a small budget uses OR and -word in real queries.

intitle:, allintitle:, inurl: and filetype:

  • intitle:tesla: 100 of 100 titles had tesla. The plain tesla control had 102 of 103, so this test can't show that intitle: filters.
  • allintitle:tesla rivian: an empty feed.
  • inurl:reuters: 6 items, 5 labelled Reuters, dated 2018-12 to 2025-12. We can't check URLs, and it is not a usable filter.
  • electric vehicles filetype:pdf: 30 items instead of about 100, none with a PDF title. A PDF need not say so in its title. Something changed, but we don't know what. We repeated it once and got 30 again.

In the Google Alerts web preview, we found intitle: filtered and allintitle: did not. That is a different surface, and we did not retest it here.

before: and after: dates

Dates use YYYY-MM-DD. after:2026-10-15 before:2026-10-18 returned 100 items dated 15 October 09:15 to 18 October 07:00 UTC. after:2026-10-01 before:2026-10-10 returned 100 items, all in October, 92 before 10 October and 8 dated 10 October or later.

before:2026-10-10 alone leaked: 2 of 100 were dated later, in a repeat run. after:2026-10-15 alone showed only the newest days (19 to 22 October), because the cap cut the older ones. And when:7d after:2026-10-20 ignored after: entirely: the 100 items ran from 15 October.

This answers the untested before:/after: line in the Alerts post, for the feed only.

Topic and top-stories feeds don't take a query

  • Top stories (/rss) returned 38 items.
  • /rss/headlines/section/topic/TECHNOLOGY returned a 302 to /rss/topics/<id>.
  • Appending &q=when:1d to that section URL returned a 302 to /rss/search. We did not follow it to see where it ended.
  • /rss/search?q= returned a 404.

For topic URLs, see Google News topic IDs that still work.

What we would do next

Not tested: other languages, other IPs, other query families, ranking quality, related:, link:, cache:. Repeating the matrix across a week would show how much of this moves. For what repeats inside the results themselves, see how often a Google News RSS feed repeats the same story.

Skip the plumbing

A Google News source in Feedmarkdown takes a query string, such as site:<domain> offshore wind when:1d, and sends it to the same endpoint. We pass your string to Google and have not run these operators through Feedmarkdown, so we promise nothing beyond that. The service resolves the publisher URL, removes duplicates across sources before scraping, and delivers full-text Markdown by signed webhook or as a JSON Feed 1.1 or Atom feed you pull. Plans are on the pricing section of the home page.