Solutions
SEO monitoring: no rankings, and the part we can do
Start with the disqualifying fact. We cannot fetch search engine result pages, so we cannot track your keyword positions. If that is the whole job, buy a rank tracker and stop reading. If your SEO work also involves watching what your own and your competitors' pages actually return, that part is a plain HTTP fetch.
What we do not offer
No search engine results and no rank tracking of any kind. Not Google, not Bing, not any of them: no positions, no SERP features, no featured snippets, no local pack, no keyword volumes. Search engines serve a JavaScript challenge to datacenter addresses, every address we have is a datacenter address, and we run no headless browser to solve a challenge with. We published a search endpoint once and withdrew it rather than sell one that returns a challenge page. There is also no backlink index — we do not crawl the web and hold no link graph — no site crawler, no scheduler, and no page-speed or Core Web Vitals measurement, because each of those needs something we do not run.
Why the answer on rankings is no, and stays no
The mechanism is worth understanding, because it predicts which other targets will fail too. Search engines classify the address a request arrives from, and traffic out of cloud provider ranges gets an interstitial that has to be executed in a browser before any results appear. An address in an AWS range is overwhelmingly likely to be automation rather than a reader. Our egress nodes are EC2 instances in our own AWS account, which is precisely the range being classified.
Two things could change that: residential egress, or a headless-browser tier that executes the challenge. We operate neither, and both are a different business with a different cost base. So this is not a roadmap item being worked through and it would be dishonest to present it as one. It is a no, and you should plan around it.
Most SEO monitoring is not the result page at all
Rankings are the outcome. Almost every input to them is something a server hands you when you ask, and asking is what we sell. You supply a URL; the response comes back with the body, the status the target answered with, and its content type.
Titles, descriptions and canonicals
All in the served HTML. A template change that dropped the canonical link element off a section of the site is invisible to a person spot-checking pages and obvious to a diff.
Meta robots
A noindex left behind after a staging release is the classic silent traffic loss. It is one line in the markup you already fetched.
Structured data
JSON-LD sits in the page. Fetch it, pull the script block, and validate it against what your rich results depend on. A Product block that lost its price field after a deploy is a real regression with no visual symptom.
hreflang and locale variants
Worth verifying rather than trusting, especially on sites where the alternates are generated.
Status codes and redirects are the highest-value monitor
The envelope reports the status the target itself answered with, not just the status of our call. So a page that started returning 404, a 301 that someone downgraded to a 302, a URL that now lands somewhere unexpected — these are visible directly, and they are exactly the failures that cost traffic quietly because the site still looks fine to whoever opens it in a browser.
Two fields carry the redirect story. final_url is the URL that actually produced the body you got back, and redirects is the number of hops it took. Together they tell you whether a URL is still serving what you think it serves. A migration is precisely when to watch both on every URL you care about.
Egress nodes never hand redirect-following to the HTTP client. Each hop is resolved and re-validated against the address the next connection would use, under a cap on hop count. That is an SSRF control rather than an SEO feature, but the effect is the same: the chain is walked deliberately rather than blindly.
robots.txt and sitemaps
Both are files at known URLs, both are cheap to fetch, and both are usually unmonitored. A robots.txt that gained a Disallow line during a release is one of the highest-consequence single-line changes anybody can ship. It is a text file. Fetch it on a cadence, keep the last copy, diff.
Sitemaps are also how you get a URL list without a crawler. Fetch the sitemap index, parse it yourself, then fetch the URLs it names. For a site you own that is usually better than crawling: you are checking the exact set of URLs you chose to publish, and you find out when one of them stops resolving.
Competitors' pages, from three regions
The same call works on somebody else's site. Which pages exist, which stopped existing, how their titles and descriptions are written, what structured data they emit. It is a public page and reading it is what it is for.
Region is a query parameter, so you can fetch one URL from us-east, us-west and europe and compare. Sites that vary by geography — different copy, different currency, a redirect into a country subdirectory — reveal it immediately, and a geo-redirect firing on a URL you intended to be globally canonical is worth knowing about.
What you build
We return the response. Everything after it is yours: the parser that pulls the title and the JSON-LD, the schedule that decides when to check, the store that keeps yesterday's version so there is something to diff against, and the alert that reaches a person. There is no scheduler here and no extraction service.
Questions
- Can you track my Google rankings?
- No. Not for a short keyword list, not in a limited way, and not with a workaround. Datacenter addresses receive a JavaScript challenge instead of results, every address we have is a datacenter address, and we run no browser to execute the challenge.
- Do you provide keyword volume or difficulty data?
- No. Those are data products built on a search engine's own signals and on large-scale crawling. We have neither, and we would have to invent the numbers to publish them.
- Can you crawl my whole site?
- There is no crawler and no scheduler. You supply URLs one at a time. In practice the workable pattern is to fetch your sitemap, parse the URL list out of it in your own code, and fetch those URLs.
- Do you measure page speed or Core Web Vitals?
- No. Those are browser measurements and we run no browser. Each response does report how many milliseconds our egress node spent on that one fetch, which is a per-request diagnostic — it is not field performance data and should not be reported as one.
- Can I monitor a staging or internal site?
- Only if it is publicly reachable. Nodes resolve the hostname and refuse private address ranges and cloud metadata endpoints, so a host that only exists inside your network will be refused with an error rather than fetched.
Get a key
Create an account and mint an API key in the dashboard. The full endpoint reference — request shapes, parameters and error codes — is published at https://api.roamingproxy.com/v2/docs.