How to automatically show the latest, most popular press releases on your website

Define “latest” and “popular” separately

Latest is a chronological question: which announcements were published most recently? Popular is a measurement question: popular by clicks, readership, saves or some other signal? The two need different data.

A source may provide timestamps without audience data. In that case, sort by publication date and label the list “latest.” Only use “popular” when you have a clear metric and a time window, such as the most-read releases on your own website this week. If you cannot say what a list is ranked by, your readers cannot either, and a heading like “trending” becomes a claim you are unable to support.

Choose an API or a source feed

You have three practical starting points, and they suit different sites.

A syndication API. The Press Release API syndication path is designed for filtering by niche, keyword, company type, language, provider and brand. Providers include GlobeNewswire, ACCESS Newswire, PR Newswire and Newsfile, and brand filters cover names such as OpenAI, Adobe, Google, Tesla and Meta, which are examples and not endorsements. It fits best when you want one filtered stream across several sources instead of stitching feeds together yourself. Signup is free, and usage is free up to 1,000 results per month, then $0.10 per additional 1,000 results.

Official RSS feeds. For a source-specific option, evaluate the official PR Newswire RSS feeds and GlobeNewswire RSS feeds. RSS is simple and widely supported, and a single feed may be all a small site needs. The trade-off is that each feed covers one source, so merging, filtering and deduplicating across feeds is your job.

A searchable database. Begin in your dashboard and continue to Press Release Database to explore current announcements. Browsing real releases first is the quickest way to learn which niches, keywords and providers produce items your readers would want, before you write any code.

Whichever route you choose, confirm its current access and reuse terms before using content commercially. Being able to fetch a release does not mean you may republish its full text or images.

Create a small ingestion pipeline

Do the work on your server, on a schedule, and let visitors read from your own storage. The steps are the same in any language:

1. Fetch. A scheduled job requests the feed or API at a fixed interval. Keep credentials in server-side configuration and out of public JavaScript.
2. Parse and validate. Check that the response has the shape you expect. Discard items missing a headline, a date or a source link instead of publishing them half-empty.
3. Store. Save stable IDs, timestamps and source URLs, along with the text you are permitted to show.
4. Deduplicate. Skip any item whose ID or source URL you already hold.
5. Publish. Render pages from your stored copy, never from a live call made while a visitor waits.

Retry temporary failures with backoff: wait a little, then longer, then stop and alert someone.

Cache responses and keep the last good data

Use a server-side cache so every visitor does not trigger a new paid retrieval. With Press Release API, a result is one release returned, so a page that calls the API on every view multiplies your usage by your traffic. A scheduled fetch keeps the number predictable, because it depends on how often the job runs and not on how many people visit.

A sensible starting configuration, described in words: run the job every thirty minutes, store only items you have not seen before, keep the most recent successful response in your database, serve every page from that copy, and alert a named person if no fetch has succeeded for a few hours. Adjust the interval to your niche. A fast-moving sector may justify more frequent checks. A regional business section rarely does.

Do not let a provider outage empty your homepage: continue serving the last successful data and monitor the fetch job. A news box that is an hour old looks far better than one showing an error. Display the date on each item, so readers can judge freshness for themselves.

Filter, deduplicate and review

Start with one topic and a short allowlist of trusted providers. Normalize company names, so that “Example Corp”, “Example Corp.” and “EXAMPLE CORPORATION” group under one profile. Ignore duplicate IDs, and watch for the same announcement arriving from two sources with different IDs; comparing the normalized headline and company usually catches it. Validate links before publishing.

Treat remote text as untrusted input: escape text and sanitize any allowed HTML. In practice, output-escape headlines, company names and summaries in your templates. If you display release bodies with formatting, pass them through a well-maintained sanitizer library that permits a short list of tags, such as paragraphs, links and lists, and strips scripts, inline event handlers, frames and styles. Accept only http and https links. One unescaped field is enough to put someone else’s script on your pages.

Route sensitive or unusual announcements to review. Financial results, health claims, legal disputes and anything about a named individual are reasonable triggers for a human look before publication. A feed should help your editorial process keep pace, rather than remove the process altogether.

Present the source clearly

Label the section as press releases. Each item is the issuing organization’s own statement, not your reporting, and readers deserve to know which is which. Every item should carry:

• a descriptive headline;
• the company that issued the release;
• the original publication date;
• a source label naming the provider;
• a link to the original announcement;
• a note explaining whether a summary was edited or shortened.

Follow the licensing requirements of each source. If your rights cover only a headline and an excerpt, show those and send readers to the original for the rest. Keep attribution intact when items appear elsewhere on your site, such as a homepage widget or a newsletter.

Measure popularity yourself, and keep tuning

For popularity, count your own meaningful engagement while excluding obvious bots; use a recent time window so older releases do not dominate forever. A workable definition is views of the release page by distinct visitors over the past seven days, recalculated by a scheduled job. Say what the ranking means near the list, for example “most read on this site this week,” and fall back to the latest list when you have too little data to rank anything.

Revisit your filters when irrelevant items start appearing, and monitor result usage against your budget. A monthly look at what was imported, what was read and what was removed by an editor is usually enough to show which keyword is too loose or which provider no longer fits. The section should become narrower and more useful over time, not simply larger.