Website bot filtering: rules you can verify
A bot and fraud filter helps manage automated requests to your website. Begin with observation and rule checks: an incorrect block can affect visitors and legitimate search crawlers.
Define the requests you want to handle
Automated requests may come from a search crawler, monitoring service, parser or scraper. The goal is to allow useful access while limiting unwanted requests to your website and landing page. List the protected paths and permitted actions first: reading a page, following a button or fetching a static file. Identify your own monitoring and service checks separately. Automation alone does not establish abuse, and the number of rejected requests is not a useful quality target. A successful policy is understandable and preserves access for the intended audience. Start on one website or test flow so configuration mistakes are visible before broad enforcement.
Signals provide evidence with limitations
inotrack uses crawler and data-center ASN databases, JS fingerprinting and rules based on User-Agent, IP, ASN, referer and geography. Each signal has limitations. A client name in User-Agent can be forged; a data-center address can belong to a useful service; a missing referer does not prove automation. Interpret signals in the context of the website and inspect why the rule matched. Avoid turning one unusual header into a universal ban. Investigation needs a reproducible request and the rule version active at the time. Use controlled examples without publishing real visitor addresses or unnecessary information from logs.
Make rules and responses understandable
The bot and fraud filter supports presets, a placeholder response or challenge for bots, and a custom placeholder for each website. Choose the response around the protection goal and page availability requirements. A broad country or ASN rule can affect ordinary users as well as unwanted requests. Before enforcement, record the condition, expected response and allowances for permitted services. Test a matching request and a nonmatching request. If the result is unexpected, inspect the condition chain rather than layering further bans over an unexplained problem. Keep a clear rollback sequence and assign someone to review reports of inaccessible pages.
Begin with dry-run before enforcement
Dry-run lets you evaluate who a rule would affect before enabling blocking. Observe ordinary traffic first, test the proposed condition and inspect examples of matches. Visit the site using a normal browser, an environment with JavaScript restrictions and an allowed monitoring service. These tests do not replace real logs but can reveal obvious mistakes. Change one condition at a time and compare equivalent periods. If matches rise sharply, investigate whether the cause is audience composition, script availability, a rule update or a broken page. Enable the operational response only after explaining the result, and continue watching behavior after activation.
Automatic zone blocking needs context
A zone is a placement identifier supplied by a traffic source. It is not an arbitrary visitor or the entire website. inotrack supports automatic blocking of poor zones and shows whether an entry came from a manual action, an automation rule or automatic blocking. Verify the zone parameter first so unrelated placements are not combined under an empty value. Review observation volume and matching behavior, then verify which action actually applies to the zone. A brief burst of test requests should not become a judgment about an entire source. Regularly review the list, reasons and process for restoring an allowed placement.
Check access for search crawlers
Do not trust a search engine name in User-Agent alone or block every automated request with one broad pattern. In inotrack, reverse DNS verification runs in the background with IP and subnet caching. A new crawler may receive a placeholder before verification completes, so unconditional immediate access cannot be promised. Check crawler access before launch and after rule changes, including repeat requests and verification results. If a problem appears, narrow or disable the disputed condition and test again. The feature page explains the implementation, the rules page covers actions, and the linked article connects observation with a systematic protection workflow.
Questions
Is User-Agent alone enough for blocking?
It is easy to misinterpret. Check other signals and context, then evaluate the condition in dry-run first.
Do search crawlers always pass immediately?
No. A new crawler may receive a placeholder before reverse DNS verification completes. Monitor access and verification results.
Read next
Run inotrack on your own server
One command on a clean VPS, 10–15 minutes. Get your key right after you pay on the site, or a free one for 7 days.
Questions? Message us on Telegram: @SmokeJung.