Understanding and mitigating requests to /meta.json

Over the past few weeks, our team at redirection.io has observed a significant increase in automated traffic from Meta (Facebook) targeting a specific path: /meta.json.

If you monitor your website logs, you may have noticed an influx of requests from the facebookexternalhit/1.1 user agent directed at this non-existent file (the exact user agent string is facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)). While Meta has not yet officially documented the purpose of these requests, the data we have collected across thousands of domains allows us to shed some light on the situation.

What the data tells us

Based on our internal metrics, this is not an isolated phenomenon but a widespread systematic probe:

  • Broad reach: Approximately 17% of all domains monitored by redirection.io are receiving a significant volume of these requests.
  • High traffic volume: For affected domains, these requests typically represent 1% of total traffic.
  • Extreme cases: On certain websites, the /meta.json path can account for up to 20% of all incoming requests (and in one specific case, it reaches 34%).
  • Campaign links: About 65% of these requests include query strings containing real campaign names or tracking parameters.

Why is Meta doing this?

The presence of campaign-specific parameters strongly suggests that these requests are part of an automated verification process. Meta is likely checking for a standardized configuration file - possibly related to Meta Ads, the Conversions API (CAPI), or Business SDK health checks - to verify how a landing page handles tracking or metadata.

The requests originate from official Meta IP ranges (for example from the CIDR 69.171.224.0/19, 69.63.176.0/20 or 173.252.64.0/18, etc.), confirming that this is legitimate crawler behavior rather than a malicious attack. However, because most websites do not host a meta.json file, these requests result in "404 Not Found" errors.

The impact on your website

While a few 404 errors are harmless, the volume of these requests can cause real issues:

  1. Server strain: Each time a crawler hits your site, your backend (CMS or application) may have to "boot up" to generate a 404 page, consuming CPU and memory.
  2. Log pollution: Your analytics and error logs can become cluttered with thousands of useless entries, making it harder to spot real technical issues.
  3. Scalability: For sites where this traffic reaches 20% or more, it can unnecessarily slow down legitimate human visitors during peak times.

How to mitigate the issue

If your website does not intentionally use a meta.json file (for example, for a PWA or a specific JS framework), there is no benefit to letting these requests reach your server.

The most efficient way to handle this is to intercept the requests at the "edge", before they even reach your hosting provider. We recommend implementing a rule that returns a clean 404 status code with an empty body. This informs the crawler that the file doesn't exist while saving your server's resources.

We have created a ready-to-use recipe for redirection.io users to solve this in one click 👉 Block meta.json requests