How to Monitor News and Social Mentions of Your Brand (Without an Enterprise Tool)

Quick answer: You can build a working brand mention monitor with a search API, a cron job, and an LLM. Run scheduled searches for your brand terms across news and the web, dedupe against what you've already seen, run new mentions through an LLM for sentiment and relevance, and alert on anything notable. The honest caveat is social platforms: their APIs are restricted and their terms prohibit scraping, so a DIY monitor covers news, blogs, forums, and the open web well, and social platforms only partially.

I run a version of this for link.sc itself. Here's the architecture, the code, and where the real limits are.

The Architecture

Four stages, each simple on its own:

Stage	Job	Tooling
Collect	Scheduled searches for brand terms	Search API + cron
Dedupe	Drop URLs you've already processed	A database table
Classify	Sentiment, relevance, urgency	An LLM call per new mention
Alert	Notify on what matters	Slack webhook, email

The whole thing is a few hundred lines. Enterprise media monitoring tools add breadth (broadcast, print, historical archives) and polish, but for "tell me when someone writes about us online," this pipeline covers it.

Stage 1: Scheduled Search Queries

The collection layer is a set of search queries run on a schedule. Beyond your brand name, query the variants people actually use:

• The bare brand name, quoted: "link.sc"
• Brand plus context terms: "link.sc" API review
• Common misspellings if your brand has them
• Founder and product names
• Your domain mentioned outside your own site: "link.sc" -site:link.sc

That last one uses a search operator to exclude your own pages, which cuts noise dramatically. A collection call through link.sc looks like this:

curl https://api.link.sc/v1/search \
  -H "x-api-key: lsc_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "q": "\"link.sc\" -site:link.sc",
    "engine": "google"
  }'

Recency matters here: for monitoring you want what's new, not the all-time top results. There's no recency parameter on the search call, so the dedupe stage does that work; run the queries on a schedule and only URLs you haven't seen move forward. One detail that makes link.sc a good fit for this job specifically: the same API that runs the search will fetch any result as clean markdown, so the sentiment stage can read the entire article instead of judging from a title and description, which is the same property that makes it useful for real-time web search in LLM apps.

Run the query set every hour or every few hours depending on how fast you need to react. For most companies, hourly is plenty.

Stage 2 and 3: Dedupe, Then Let an LLM Read Everything

Dedupe is unglamorous and essential. The same article will appear in results for days, and syndicated stories appear under multiple URLs. At minimum, keep a table of seen URLs (normalized: strip tracking parameters, trailing slashes) and skip anything already in it. A step better is hashing the first few hundred words of content so syndicated copies dedupe too.

Then classification. This is the part that used to require a sentiment analysis vendor and now is one LLM prompt. For each new mention, you want to know: is this actually about my brand (the hard problem for ambiguous names), is it positive, negative, or neutral, and does it need a human now.

Here's the pipeline core in Python:

import requests

LINKSC_KEY = "lsc_your_api_key"

def collect(query: str) -> list[dict]:
    resp = requests.post(
        "https://api.link.sc/v1/search",
        headers={"x-api-key": LINKSC_KEY},
        json={"q": query, "engine": "google"},
    )
    results = resp.json().get("serpData", {}).get("results", [])
    return results[:20]

def fetch_content(url: str) -> str:
    resp = requests.post(
        "https://api.link.sc/v1/fetch",
        headers={"x-api-key": LINKSC_KEY},
        json={"url": url, "format": "markdown"},
    )
    return resp.json().get("content", "")

def classify(mention: dict, content: str, llm_call) -> dict:
    prompt = f"""You monitor brand mentions for "link.sc", a web fetch/search API.
Analyze this page and answer in JSON with keys:
relevant (bool, is it genuinely about the brand),
sentiment (positive/neutral/negative),
urgent (bool, needs human attention today),
summary (one sentence).

Title: {mention['title']}
URL: {mention['targetUrl']}
Content: {content[:4000]}"""
    return llm_call(prompt)  # your LLM client of choice

seen = set()  # in production, a database table

for result in collect('"link.sc" -site:link.sc'):
    url = result["targetUrl"]
    if url in seen:
        continue
    seen.add(url)
    content = fetch_content(url)
    verdict = classify(result, content, llm_call=my_llm)
    if verdict["relevant"] and (verdict["urgent"] or verdict["sentiment"] == "negative"):
        notify_slack(verdict["summary"], url)

Two practical notes from running this. First, the relevance check earns its cost: without it, a brand named after a common word drowns you in noise. Second, send the LLM real page content, not just the snippet. Snippets routinely misrepresent sentiment; an article titled "Why I stopped using X" is sometimes a glowing review of the migration target.

Stage 4: Alerting That People Don't Mute

Alert design decides whether this system gets used or ignored. My rules:

• Immediate alerts only for negative sentiment or high-urgency mentions. These go to Slack.
• A daily digest for everything else: one message listing new mentions with sentiment and one-line summaries.
• Weekly trends if you want them: mention volume over time, sentiment ratio. A cron job and a chart.

If every mention pings the channel, the channel gets muted within two weeks and the one negative story that mattered scrolls past unread. Route by severity from day one.

The Honest Part: Social Platform Limits

Now the caveat I promised. "Monitor news and social mentions" is really two problems, and the second one is constrained by things no tool fully escapes.

X, Reddit, LinkedIn, TikTok, and Instagram all restrict API access, and their terms of service prohibit scraping logged-in or private content. What that means in practice:

• Public, indexed social content shows up partially in web search. Reddit threads in particular surface well, and operator queries like site:reddit.com "yourbrand" catch a lot.
• Platform-native search (inside X, inside LinkedIn) sees more, but programmatic access ranges from expensive to unavailable, and scraping it violates ToS. I'm not going to tell you to do it.
• Enterprise social listening tools pay for official data partnerships. If social is where your brand conversations actually happen, that's what you're buying when you buy one, and it's the legitimate reason to pay.

My honest framing: the DIY pipeline gives you excellent coverage of news, blogs, forums, review sites, and the indexed web, which for most B2B brands is where the mentions that affect deals actually live. If you're a consumer brand living and dying on TikTok, budget for a social listening platform and use the DIY pipeline for the open web alongside it.

Start Small, Then Widen

Day one version: one query, one cron job, one Slack webhook. You'll have it running in an hour, and you'll learn from real mentions which queries and thresholds you actually need. The link.sc docs cover the search parameters, and 500 free credits a month covers hourly monitoring of a couple of queries while you evaluate.

---

Want to know when the web talks about your brand? Sign up for link.sc and build your monitor on 500 free credits a month.