Home / Knowledge Base / Straight answers / How Publications Are Made: IPs, Accounts, Behavior

How Publications Are Made: IPs, Accounts, Behavior

Straight answers 3 min read Updated 12.09.2026
Different IPs are a minimum, not an advantage. We analyze all layers: a real browser instead of a form request, ISP proxies, anti-detect, captchas, registration emails, and publication tempo.

“Publications from different IPs” is a minimum, not an advantage: mere IP diversity is no longer sufficient. Below is what actually happens with each publication, including those layers that are usually not discussed: browser fingerprint, behavior, captchas, and registration email.

Publication goes through a real browser

The placement is not an HTTP request to a form, but an automated Chromium: the login page opens, fields are filled, the same site scripts are triggered as with a live user. This is noticeably more expensive than a simple POST request, but this is how publication passes where there is at least some protection, and it looks like a normal session, not a bot.

Automation is launched with an anti-detect layer: signs of a controlled browser are hidden, and the environment — window size, language, time zone, capabilities set — looks like an ordinary user configuration, not like a default headless.

Network layer

ChannelWhen used
ISP proxies — static addresses of real providersMain publication channel: stable address, live session, cookies are preserved
Residential rotating addressesRegistrations and multi-step scenarios where a fresh exit is needed
Antibot gatewayRetries and sites with strict protection: takes on the passing of checks

Each proxy is checked for liveliness before use; non-working ones are marked and excluded. Publications from the server IP of the platform do not go through — such an address quickly becomes recognizable.

Captchas

Some sites are closed with checks: Cloudflare challenge, hCaptcha, reCAPTCHA, Turnstile. For them, proprietary solvers and external recognition services are used. Where the check cannot be passed consistently — the site is simply excluded from the pool, rather than remaining “sometimes working”: half of the failed publications are worse than the absence of the site.

Accounts and email

  • Accounts are registered on a proprietary email domain with reception on all addresses — registration confirmation comes and is processed automatically.
  • There is a limited number of publications per site within one launch: the reuse parameter for the site is set by settings and does not allow the entire cascade to go to one domain.
  • Accounts and sessions are stored and reused: an account with a history of publications looks more natural than a newly created one.

Publication tempo

The cascade does not publish everything in one hour. In natural mode, publications are distributed unevenly over time, in normal mode — they go in parallel streams with a limit on simultaneous tasks. The average duration of a completed launch is about 17 hours (based on 286 launches since July 2026).

What one IP diversity does not solve
If all donors link only to one site, no rotation of addresses will hide this — connectivity is visible from the links themselves. Therefore, it is more important that the sites are public and thousands of external authors publish on them: this is a separate article about network footprint.

What happens after publication

  1. The publication address is saved in the report.
  2. A check is launched: the page is reopened and your link is searched for — see why only verified links are in the report.
  3. The publication is sent for indexing, the status is checked in search — see indexing of publications.
  4. If the slot is not confirmed, it is reallocated to another site at our expense.

FAQ

Do publications go from different IPs?
Yes, through ISP proxies and residential addresses, and publications do not go from the server address of the platform at all. But mere diversity of addresses is not enough — the composition of the sites and the variety of anchors are more important.
Do you use a real browser or API requests?
A real browser with an anti-detect layer: the page opens, forms are filled, the same site scripts are triggered. This is more expensive, but it passes where there is protection.
What about captchas?
Proprietary solvers and external recognition services are used. Sites where the check cannot be passed consistently are completely excluded from the pool.
Try it on your project Everything described in the article is available in the dashboard — the registration bonus is already in your balance.
Open dashboard
Was this article helpful? Thank you! We will consider this in future updates.