Server-side cloaking is a filter that makes its decision on your site's server: the visitor's request reaches the hosting, PHP code asks the filtering service who is there, and only after the answer does it send the browser the offer or a neutral page. Client-side cloaking works differently: the page is already loading, and a JS tag in its <head> hides the content, checks the visit and shows the right version.
Both setups solve the same task (weeding out bots, scanners, spy tools and off-target traffic), but they see a visit from different sides and fail in different ways. Step-by-step installation is covered in how to install a cloaker: JS tag or PHP; here we look at the architecture: what happens inside and where each method is strong and weak.
Server-side cloaking: how the request flows
The path of a visit in the server-side setup:
- The visitor clicks an ad, and the browser requests
your-site.com. - The request reaches your server, and the PHP file answers first, not the landing page.
- The file sends the request data to the service: IP, headers, link parameters.
- The service checks the visit and returns a decision.
- The server sends the browser the offer or the White Page. Until this moment the browser has not received a single byte of the page.
The key property is that the page does not go to the visitor before the decision. A bot has nothing to save, an ad blocker has nothing to cut and a slow connection has nothing to show too early.
Client-side cloaking: how a JS tag works
In the browser-based setup the order is reversed:
- The browser requests the page, and your hosting serves it to everyone the same way.
- The tag sits as the first line of
<head>: it loads before everything else and hides the page. - The tag collects browser signals and sends them to the service.
- If the decision is "offer", the page is shown. If it is "White Page" or there is no decision, the visitor is taken to the neutral page.
The upside is simplicity: the tag goes into any page whose <head> you can edit, even on a site builder without your own server. The downside is that the landing page HTML is physically in the browser already. The tag hides it but cannot "not send" it.
What each cloaker sees about a visit
The main difference between the architectures is the set of signals.
| Signal | Server | Browser |
|---|---|---|
| IP, provider, network, country by address | Yes | Yes, via the service |
| User-Agent, language, referrer, request headers | Yes | Yes |
| Link parameters: fbclid, gclid, ttclid, UTM | Yes | Yes |
| Whether the client runs JavaScript | No | Yes |
| Browser time zone and language | No | Yes |
| Signs of automation (webdriver, headless) | Partly, from headers | Yes |
| Screen, platform, browser properties | No | Yes |
| Mouse movements and touches | No | Yes |
| Time spent on the page | No | Yes |
The server sees the request; the browser sees the environment in which the request runs. Both will catch a simple bot from a data center. An automated browser on a residential proxy with a proper User-Agent cannot be told from a person by a single request on the server; it is given away by JavaScript behavior: a time zone that does not match the address's country, traces of automation, no movement. More on such signs in headless browser detection and fingerprinting and VPN, proxy and data center IP detection.
Hybrid: a server decision plus a check page
That is why a purely server-side setup is rarer in practice than it seems. The server-side filter decides right away when the request makes everything clear, and in borderline cases returns a short check page: it runs JavaScript, collects browser signals and asks for the decision again. For a person that is a fraction of a second of waiting; for a simple bot it is a dead end.
The ArtisanClo PHP file works exactly like this: if the flow's rules require JavaScript or a minimum time on page, the visitor sees a waiting page and is checked again. With the Keitaro filter or the Binom gate, however, there is no check page: the decision is made from the network and request signs only, so the JavaScript check and time on page do not apply there.
Speed: where the milliseconds go
Any filter adds decision time to page loading. The difference is where.
- The server-side setup adds a request from your hosting to the service before the first byte is sent. Speed depends on your hosting's network connectivity: a good server in a data center responds fast, while overloaded shared hosting slows down both the landing page and the check.
- The browser setup adds loading the script and a request from the visitor's browser. On mobile internet this is more noticeable, but the page is loading in parallel, so it does not need to be downloaded again after the decision.
- The check page adds waiting on purpose. Turn it on where the source justifies the strictness, not everywhere by default.
In practice, a landing page with a dozen analytics scripts and heavy images loses more time than either filtering method. Optimizing the page usually gives more than choosing the architecture.
Reliability: how a cloaker behaves during outages
Fault tolerance is where the architectures differ the most.
If the JS tag did not load
The tag is an external script. If the network, a corporate filter or a server-side blocker did not let it through, the page simply will not be hidden, and everyone sees it, including bots and spy tools. Here the failure is "open". If the tag loaded but there is no decision, it takes the visitor to the White Page; that failure is "closed".
If the service did not answer the server
The server-side method waits for a response for a limited time. In ArtisanClo the PHP file waits up to 4 seconds, and if the connection is lost it serves visits for a day based on the last response received: visitors with an ad click ID go to the offer, everyone else to the White Page. A visit that arrives before the very first response gets a 503 error. The Keitaro filter and the Binom gate have a 3-second limit, after which the visit goes to the White Page.
If the hosting went down
Here both setups are equal: the landing page lives with you, and the filter will not bring a dead server back. The service is responsible for the decision; you are responsible for the page's availability and its certificate.
| Situation | JS tag | PHP file |
|---|---|---|
| Script blocked along the way | Everyone sees the page | Not applicable |
| Service did not respond | White Page | Works on the last response for up to a day |
| Hosting blocks outgoing connections | No effect | 503 error, slow loading |
| Hosting web application firewall (WAF) | Usually no effect | May cut check requests |
Caching, CDNs and proxies: the quiet enemies of server-side cloaking
The server-side setup relies on every request reaching the PHP file. Three things get in the way.
- Page caching. A caching plugin, hosting cache or CDN serves a saved copy without asking for a decision. As a result everyone sees the same page, whichever one ended up in the cache. A landing page with a filter must be excluded from caching. HTML caching bothers the tag less: the script inside the copy still runs in the browser, as long as the copy was made after the tag was installed.
- A proxy in front of the site. If the hosting puts its own proxy in front of the server, the PHP file sees the proxy's address instead of the visitor's, and the filter evaluates your server rather than people. The symptom: every visit in the log has the same IP. The fix is passing on the real address (a real IP setting) or proxying through Cloudflare, whose headers the file understands.
- Decision caching in the browser. To avoid asking the service on every reload, the decision for one visitor may be stored for a short time. In ArtisanClo with the PHP file it is up to a minute, so after editing a flow, check in a new incognito window.
These and other faults are covered in cloaker not working: troubleshooting.
What only the server-side setup can do
Some capabilities are physically unavailable to code in the browser.
- A status code instead of a page. The server can respond with 403 or 404, like a closed URL. A tag cannot change the status code; an empty page would remain in its place.
- Shadow mode. Every visitor goes to the offer, and the log shows whom the filter would have cut. This is how a new rule is tested without losing traffic.
- Tracker mode. The filter cuts no one; it only counts clicks, conversions and money and marks bots in reports. It suits traffic that needs tracking rather than filtering; more in what an affiliate tracker is.
In ArtisanClo, Shadow mode and Tracker mode work with the PHP file, the Keitaro filter or the Binom gate; on the JS tag the flow filters like a regular cloaker.
Updates and maintenance
Another difference people do not think of right away is who is responsible for keeping the code on the site up to date.
- The JS tag is loaded from the service on every visit. When the service improves its browser checks, every site with the tag gets the new version automatically, with nothing to change on your side.
- The PHP file sits on your hosting and does not update itself. The check logic and bot databases live on the service side, so the filter's core work improves without you, but new capabilities of the file itself require replacing it. In ArtisanClo a "You're running an older file" notice tells you about this, with a list of what your current version cannot do.
In both cases the flow settings are stored in the dashboard, not in the code on the site. Change countries, strictness or the White Page and the changes take effect from the next visit; there is no need to re-upload the file or paste the tag again.
It is also worth remembering about access rights. The PHP file runs on your server, so take it only from the service's dashboard and do not edit it by hand: an "improved" file from a chat or a forum can do anything at all on your hosting.
PHP cloaker or JS tag: which to choose
| Your situation | What fits |
|---|---|
| Site builder without server access | JS tag |
| Your own hosting with PHP | PHP file |
| WordPress | The plugin, which installs the same server-side method |
| You need tracking without filtering or shadow testing of rules | PHP file |
| Traffic already goes through Keitaro or Binom | The tracker's filter or gate; see Keitaro cloaking integration |
| Hosting blocks outgoing connections | JS tag |
In short: the tag is quicker to install, the server-side method is more reliable and offers more modes. Filtering settings do not depend on the architecture: they live in the flow, and you can switch connection methods without editing the rules. For a comparison with self-hosted scripts, which are also often called "PHP cloakers", see cloud cloaker vs cloaking script.
Tip. Whichever setup you choose, after installing it open the ad link in incognito and find your visit in the click log. The decision reason immediately shows whether the filter sees the real IP, whether the check fires and whether the cache is serving an old copy.
Server-side filtering and ad platform rules
The architecture does not change the policy side. Ad platforms prohibit showing the ad review system something different from what the user will see, regardless of whether the server or the browser decides it. The honest value of either setup is filtering bots, click fraud, spy tools and off-target geos, clean statistics and money tracking. More on this in cloaking for affiliate marketing.
Summary
- Server-side cloaking decides before the page is sent: it does not depend on blockers and supports status codes, shadow mode and tracker mode, but needs PHP, outgoing connections and care with caching and proxies.
- Client-side cloaking goes into any
<head>and sees signals the server cannot, but the page HTML is already in the browser, and a script that failed to load hides nothing. - The best of both worlds is a server decision with a check page: the server looks at the network and the request, a short piece of JavaScript in the browser looks at behavior and environment.
- Terms, features and plan contents are on the features and pricing pages.
