Where Should You Look When Verifying Ecosia Results?
Rather than operating its own full-scale web index, Ecosia takes most of its result set from partner providers and adds its own ranking and interface layer on top. A proxy touches only the first link of this chain. This page explains how to set up your measurement independently of the source.
Source chainWhere the result set comes from and how that reflects on measurement.
02
Compliance limitsWhat robots.txt governs and where the terms of service come in.
03
Local blocksWhich signal map and business results are fed by.
04
Measurement setupA repeatable series, a reasonable tempo and evidence retention.
When examining a search engine that takes a significant part of its results from a partner provider, your first decision should be this: set up your measurement independently of the source. That is, make no inference that rests on the assumption "these results come from that engine". Source partnerships can change over time and from market to market; an assumption that is correct today will invalidate your round six months from now.
Source-independent measurement means, in practice, recording what you see exactly as it is: which query, under which conditions, from which exit, on which date, returned which results. This record retains its validity even if the source chain changes; the sentence "it comes from there" does not.
The proxy takes on a single role in this picture: it changes which network the request comes from. The region you select in the interface, the language your browser declares and the preferences sitting in your profile remain the same regardless of your exit. The sections below build this distinction step by step.
Where does a query pass through before it becomes a result page?
The chain consists of four steps, and a different party comes into play at each one. First your client prepares the query: the language list, cookies and profile preferences are added to the request at this stage. Then the request leaves through the proxy exit; this is the address the target sees. In the third step, the engine's front end receives the request and applies its own ranking and interface layer. In the fourth step, the page is compiled and returned to you.
The proxy is only in the second step. What happens in the third step — which records are pulled from which source, which block is placed on top, which markers are added — is independent of your network. That is why the observation "I changed the exit and the result set is almost the same" is not a fault but a natural consequence of the chain: the network side is only one of the inputs that shape the result.
There is another invisible part of the chain: the page does not come from a single domain. Interface scripts, icons and small resources such as favicons are served from separate addresses. If your rule covers only the main domain, the page opens but looks fragmented; this does not mean the setup is broken, it means the scope is too narrow.
Finally, the cookie side: the choice you make on the consent and preference screens that appear on your first visit stays in the profile and affects subsequent rounds. Make this choice the same way every time in your measurement rounds, or work with a completely blank profile; making different choices in two rounds makes the difference in the results uninterpretable.
DIAGRAMThe four steps of a query and the party at each step
You can scroll the diagram horizontally to inspect it
The proxy is active only in the second lane; what happens in the third lane is independent of your network.
When the region setting in the interface conflicts with the exit country
Most search interfaces let you manually select which region the results will be compiled for. This choice is carried in a cookie or in a parameter in the address bar and works independently of the network the request comes from. As a result, two signals speak at once: the region you selected and the network's geographic inference.
When they conflict, the explicit selection generally prevails, because a preference expressed by the user is stronger than an inferred signal. This does not make the proxy unnecessary; it only changes what you are measuring. A test made with an explicit selection answers the question "what does a user who selects this region see". A test made with the exit country answers "what does a user connecting from a network in that country, who has selected nothing, see". These are different questions and should be run as separate series.
The practical setup is this: in the first series the profile is opened blank, no region selection is made, and only the exit country is changed. In the second series the exit is held fixed and only the region selection in the interface is changed. Reading the two series together lets you distinguish which difference arises from which signal. Moving two variables at once in the same round produces an uninterpretable table.
The language side behaves similarly. The language list your browser sends does not change together with your exit; switching to a Germany exit does not make the interface German by itself. If you want to measure the effect of language, change the language list manually and record it as a separate series.
What are map, business and local blocks sensitive to?
Local blocks are the area where the proxy's effect shows most clearly, because on a location-sensitive query the result set responds directly to the network's geographic inference. But to see that response, the query has to genuinely carry local intent. On a conceptual query the map block does not appear at all; reading this as "the proxy is not working" is a common misconception.
The second condition is that stronger signals have been switched off. A location permission granted to the browser, a region selection sitting in the profile or a city name you typed into the search box overrides the network inference. For a clean local block test, the location permission should be denied, the profile should be blank and no city name should be added to the query text — the moment you type a city name, you have declared the location yourself.
Test purpose
Query form
Expected output
Measuring the network inference
A locally intended query without a city name
Local cards that change according to the exit country
Measuring explicit declaration
A query containing a city name
Cards for the city typed, independent of the exit
Testing the existence of the block
A conceptual query with no local intent
The map block does not appear; this is normal
The third point is resolution. The network inference is generally accurate at country level and approximate at city level. The same exit address can fall into different cities in different data sources; therefore, if you expect a precise result at city level, you also need to record the inference itself as a variable (my IP address note how the exit appears in each round using this tool).
Tiers in compliant data collection
The need to collect data from a search engine is not always the same size, and the right method varies with the size of the need. The tier diagram alongside summarises this in three steps: limited manual checks, access through official interfaces and contractually bound scaled access. As you move up a tier, what increases is not technical difficulty but the scale of permission and responsibility.
The first tier meets most needs and produces the least friction: manually opened pages, a limited number of queries, waiting between rounds and a record of every round. At this tier the proxy's role is clear — being able to look from different countries. As long as you proceed at a reasonable tempo, this is unproblematic use, both technically and ethically.
The second tier comes when a regular, scheduled need arises. Here the right approach is not to open the page automatically but to investigate the official interfaces offered by the engine or the data provider. The official route is usually more stable: the format does not change, the quota is known, and you have someone to turn to if something goes wrong. A setup based on page scraping, on the other hand, breaks every time the interface changes.
The third tier is scaled and commercial use; at this point the work stops being technical and turns into a matter of contracts and licensing. You do not move to this tier with a technical manoeuvre. For the infrastructure side of scaled reading work, the web scraping proxy and proxy selection guide helps, but infrastructure does not solve the permission side.
DIAGRAMThe access tier that changes as the need grows
You can scroll the diagram horizontally to inspect it
What increases as you move up a tier is not technical difficulty but the scale of permission and responsibility.
Determine the right exit for your checks
For session-free page reads a datacenter exit is sufficient; for local block verification, addresses leaving from a subscriber line give a more representative view.
Choose whichever you need from our residential proxies, datacenter proxies, IPv6 and ISP solutions. Every plan comes with unlimited options, 99.9% uptime, rotating proxies, sticky sessions and 24/7 support. Ideal for web scraping, ad verification, SEO monitoring and digital data collection.
ISP ProxyStatic Turkish IPs registered to an ISP
ISP-registered static Türkiye IPs; they combine datacenter speed with the reputation of a real carrier. Ideal for long sessions and low-ping use.
What does robots.txt say, what do the terms of use say?
The two documents are often confused. robots.txtis a plain text file that sits at the root of the site and tells automated crawlers which paths not to visit. The User-agent line says which software is being addressed, and the Disallow line says which path it asks not to be visited. It is a voluntary protocol: it does not technically block access, it states a request. A page you open manually in your browser falls outside this scope.
The terms of use, on the other hand, are a contract and are usually broader. Automated querying of result pages, their bulk saving or republication are governed in this document. A path may not be disallowed in robots.txt yet still be restricted in the terms of use; the two do not substitute for each other. Reading both before starting a project is cheaper than halting the work later.
The third dimension is personal data. Search results can carry people's names, contact details or content belonging to profiles. Their being publicly available does not mean they can be stored freely; storage, processing and transfer require a separate legal basis. Building your collection design around the question "what am I not storing" is the soundest starting point (KVKK disclosure notice).
Warning
Automatically passing verification screens, exceeding tempo limits or bulk querying contrary to the terms of use are outside the scope of this page. When you encounter a verification screen, the right behaviour is not to speed up but to stop the round and wait.
Which exit type suits which job?
Most work that reads search results requires no session, and this simplifies the decision. For a check that opens and closes the page without logging in, a datacenter exit is usually sufficient: it gives the highest bandwidth at the lowest cost. If you want to verify how country-specific local blocks look from a real subscriber line, a residential exit offers a more representative view.
In Europe-focused checks, choosing an exit close to the target both keeps latency reasonable and gives a more consistent picture in regional blocks. Germany and Netherlands exits are options close to the European backbone; the full list is on the proxy locations page.
The rotation decision determines the nature of the measurement. In a comparison series, a pool that changes the address on every request obscures the source of the difference: you cannot separate whether the change between two rounds comes from the country or from a new address. Work with a fixed exit in comparisons; use a pool in broad scans not intended for comparison (what is a rotating proxy).
On the cost side, two items stand out. The first is transferred data: because result pages come with interface scripts and image previews, they take up more volume than you would think. The second is concurrency: while a single page is loading, the browser opens dozens of parallel connections, and when several tabs run at once the ceiling fills faster than expected and seemingly random drops begin (concurrent connection limit).
Where should the setup be made?
The setup decision is really a scope decision, and it is made in one of three ways. A system-wide setting affects all applications; the scope is broadest, but your normal work also goes through the proxy. A browser profile covers only that profile and does not disrupt your other work. Application-based routing covers only the process you select and is the most surgical route.
For measurement work, a profile-based setup is almost always the right answer. You can open several profiles on the same machine, define a different exit for each and run rounds side by side without mixing them. A system-wide setting makes this impossible: you have a single exit at a time and every change affects the whole machine.
The protocol side is not decisive in most browser work; both an HTTP proxy and SOCKS5 work. An HTTP proxy is at the application layer and opens a CONNECT tunnel for HTTPS; SOCKS5 sits at the transport layer and does not interpret the protocol it carries. If you are going to use tools outside the browser, compatibility becomes decisive (SOCKS5 proxy).
When the setup is finished, verify three things: are the exit address and country as you expected, is domain name resolution leaking, is the browser exposing your real address through another channel? My IP address, the DNS leak test and the WebRTC leak test answer these three questions respectively. Running the tests with the proxy on and off and comparing the outputs is far more meaningful than reading the result on its own.
DIAGRAMWhat is covered depending on where you define the proxy?
You can scroll the diagram horizontally to inspect it
The scope decision determines whether you can run measurement rounds without mixing them together.
Symptoms, tempo and latency expectations
When you see something unexpected in a round, first determine which layer is speaking. The table below summarises common situations and where to look.
Status
Likely cause
Check
I changed the exit, the results are almost the same
The network inference is not the only input in the chain
Expected behaviour; test it with local blocks
The page loads fragmented
Static resource addresses are outside the rule
Write the rule so that it covers subdomains
The consent screen appears in every round
The profile opens blank, the preference is not stored
This is normal; make the same choice in every round
The map block does not appear at all
The query does not carry local intent
Try a control query with local intent
407 error is returned
No credentials, or IP authorisation has lapsed
Verify your access credentials and the authorised address
Blocking increases as the round progresses
The pace is high or the exit is shared
Stop the round and increase the waiting time
Setting the expectation about latency correctly from the start prevents later disappointment: a proxy adds a stop to the connection, so page loading takes longer in most setups and a proxy does not lower ping. A rare exception is when your default route is circuitous and the exit connects to a more direct backbone; this is not a rule and cannot be assumed without measurement (what is proxy latency).
On the tempo side, a simple principle will serve you: proceed at intervals close to human use, wait between rounds, and back off when you see a verification screen. Pressing on faster always makes the situation worse and also wears out the exit you share for other users.
Finally, the security side: who operates the server carrying your traffic is as important as whether the domains you connect to are logged. When choosing an exit, treat this question not as a technical detail but as a fundamental criterion (is using a proxy safe).
Frequently asked questions about using an Ecosia proxy
01Do I need to know which source the results come from?
To set up your measurement, no — in fact not knowing is healthier. Source partnerships can change over time and from market to market; an inference based on the assumption "it comes from there" becomes invalid when the chain changes. Record what you see together with its conditions, and base your inference on the record.
02If I select a region in the interface, does the proxy become unnecessary?
No, but the question you are measuring changes. An explicit selection answers "what does a user who selects this region see", while the exit country answers "what does a user connecting from a network in that country who has selected nothing see". Run the two as separate series.
03Should I type a city name into the query to see local cards?
If you want to measure the network inference, do not. The moment you type the city name, you have declared the location yourself and cannot see the exit's effect. Queries containing a city name are a separate test: they measure how an explicit declaration shapes the result.
04Do the choices on the consent screen affect the measurement?
Yes. That choice is stored in the profile and changes the conditions of subsequent rounds. Make the same choice in every round, or run every round in a blank profile. If different choices were made in two rounds, you cannot attribute the difference to the exit country.
05I want to collect results regularly — what is the right way?
First determine the size of the need. For limited, manually run checks, a reasonable tempo is sufficient. If there is a regular, scheduled need, the right approach is not to open the page automatically but to investigate official interfaces and data usage terms; scaled commercial use is a matter of permission and licensing.
06Why does the page load more slowly with a proxy?
Because an extra stop is inserted, the request and the response travel a longer path; this is expected behaviour and does not affect the results you record. If you suspect abnormal slowness, measure the exit with a ping test and repeat the same measurement at different times of day.
07Pool or fixed exit for a comparison series?
If you are comparing, a fixed exit. With a pool that changes the address on every request, you cannot separate whether the difference between two rounds comes from the country or the address. Use a pool only for broad scans that are not intended for comparison.
08Can these checks be done with free exits?
For a one-off look, yes; for a repeatable series, no. Free addresses are short-lived, the advertised country may not match the actual exit, and who operates the server is unknown. Do not base a measurement you will make a decision on upon these addresses.