DEV Community: webdecoy

Why crawler logs and browser analytics disagree: a five-check debugging guide

webdecoy — Fri, 23 Oct 2026 01:09:51 +0000

Your server logs show requests to an article. Your browser analytics dashboard shows almost nothing for that page. Which one should you trust?

Start with what each system measures. A request log records requests at a particular point in your infrastructure. A browser analytics tag depends on code running and a measurement reaching its collection endpoint. Those are different events.

I work on WebDecoy, where we build tools for investigating bot and AI traffic. Here is a debugging sequence you can use with your existing logs and analytics, before adding another tool.

1. Match the scope before comparing counts

Choose one hostname, one page and a short time window. Write down the timezone for both reports.

For example, compare requests for /pricing/ between 14:00 and 14:15 UTC with browser events for that same page and interval. This is a hypothetical example, not a customer measurement.

Check whether one report combines subdomains, includes query strings, or normalizes trailing slashes differently. Separate HTML requests from assets and API requests. Check status codes too: a redirect, an error response and a successful HTML response do not produce identical browser behavior.

Even after aligning the scope, a request count and a pageview count are different units. Do not expect them to match exactly.

2. Identify where the request was observed

A CDN can serve a cached response without contacting your origin. An application-level logger may therefore miss traffic that an edge log records.

Write down the observation point for each source:

Source	What it can establish
Edge request log	A request reached that edge and received the recorded response
Origin/application log	A request reached that origin or application handler
Browser analytics event	The instrumentation sent an event that the analytics system recorded

Check sampling, retention and filtering before treating any of these as a complete inventory.

3. Inspect the HTML that a client actually receives

For a page you own or are authorized to test, inspect an ordinary response:

curl --silent --show-error --location \
  --dump-header /tmp/page-headers.txt \
  --output /tmp/page.html \
  'https://your-site.example/pricing/'

Replace the example address with your own page. This command downloads the response; it does not execute the page's JavaScript.

Compare the saved HTML with the rendered DOM in your browser. Is the main text present in the response? Does it appear only after JavaScript runs? Is the analytics tag included on this route?

Google's JavaScript SEO documentation distinguishes fetching HTML from rendering JavaScript and notes that not all bots can run JavaScript. Avoid assuming every crawler behaves like Googlebot, or like the browser you use for testing.

4. Test the browser measurement path separately

In your browser's network panel, inspect whether the expected analytics request is sent. Then use your analytics provider's debugging view, where available, to check receipt.

Consent choices, content blockers, network failures and missing route instrumentation can all affect measurement. A missing browser event does not, by itself, identify a bot.

Label your own setup tests and exclude them from claims about real visitors. A successful test proves that the tested path reports under those conditions.

5. Keep identity claims separate from request evidence

A user-agent string is a client's claim. A data-center IP describes infrastructure. Neither establishes that a particular AI provider made the request, that the traffic is malicious, or that a human was absent.

Use the identity-verification method documented by a provider when available. Preserve the distinction between a declared crawler and a verified one. For other traffic, inspect request patterns and relevant session evidence before deciding how to respond.

Also keep crawls, citations and referrals separate. A page fetch does not prove that an assistant cited it or sent a person back to your site.

Turn the discrepancy into a useful finding

A useful conclusion looks like this:

In this window, the edge recorded HTML requests that were absent from the browser event stream. We checked the hostname, path, response codes and browser instrumentation. Request identity remains unverified.

That is evidence you can investigate. It gives you a better next step than classifying every unmatched request as an AI bot.

If you want to inspect bot and AI traffic through WebDecoy, choose an integration that covers the traffic you need to observe. Browser instrumentation covers executing clients; server and edge integrations cover different request paths. Explore WebDecoy and the available integrations.

Follow WebDecoy here for practical detection diagnostics. If you have a measurement mismatch, share the observation points and the counts' definitions in the comments, with private data removed.

References

Google: Understand JavaScript SEO basics
Cloudflare: Web Analytics FAQs, including the distinction between JavaScript beacon analytics and edge analytics.

Drafted with AI assistance and reviewed for the scope of each technical claim. No production accuracy benchmark or customer outcome is claimed here.

Testing WooCommerce checkout protection caught a plugin load-order bug

webdecoy — Wed, 21 Oct 2026 19:37:46 +0000

I work on WebDecoy. We set out to record a WooCommerce checkout-protection demo. Testing both checkout paths first found a real bug in our plugin.

The test used three rapid, synthetic failed orders from one test IP, then a fourth checkout attempt. A separate normal test client used an offline gateway to check that a normal order could still complete.

No real cards or payment processor were involved.

Blocks passed. Classic did not.

The Store API used by Checkout Blocks refused attempt four with HTTP 403 and webdecoy_carding. Classic checkout kept reaching the local decline gateway.

The checkout-protection setting was enabled. The validation callback was missing.

Our plugin initialized its hooks while WordPress was including the plugin entry point:

if ($this->options['protect_checkout'] && class_exists('WooCommerce')) {
    add_action('woocommerce_checkout_process', [$this, 'check_checkout']);
    // payment and checkout-attempt tracking callbacks
}

When WebDecoy loaded before WooCommerce, the class did not exist yet. The condition stayed false for that request, so classic validation and attempt tracking were never registered.

A valid setting did not mean the integration was running.

Register the integration after plugins load

Version 2.10.6 defers classic integration registration until plugins_loaded, after our includes load:

add_action('plugins_loaded', [$this, 'register_woocommerce_hooks'], 20);

That method keeps the protection-option and WooCommerce-presence checks, then registers the classic validation, payment and checkout-attempt callbacks.

We also added a runtime check to the WooCommerce compatibility smoke script. It checks the exact callbacks with has_action, so a missing callback fails the smoke check before checkout testing begins.

The fix and validation are in PR #116.

Repeat against the released package

After release, we installed the official WordPress.org 2.10.6 package in the isolated store and ran each checkout path independently, clearing only disposable test history between paths.

Environment: WooCommerce 11.2.1, WordPress 7.1 and PHP 8.3. Each failure sequence used distinct guest carts containing a $3 virtual product, an ordinary browser user-agent, and a local gateway that always fails without contacting a processor.

Test	Classic	Blocks Store API
Attempts 1–3	Local synthetic decline	Local synthetic decline
Attempt 4	JSON `failure`, suspicious-checkout notice	HTTP 403, `webdecoy_carding`
Separate normal offline order	Accepted	Accepted

Classic and Blocks use different response formats. A test expecting HTTP 403 on both would misread the classic response.

The WordPress dashboard recorded a Woocommerce card testing detection. That is the source category; the test exercised a synthetic failed-order pattern, rather than actual card authorizations. Checkout refusal is also separate from a sitewide IP ban.

What I would test on another store

The checkout path actually deployed, including Blocks if used.
A normal successful test purchase and legitimate payment retries.
The gateway’s documented test mode and any offline gateways.
Guest checkout, shared-network customers and checkout extensions.
Monitor mode versus enforcement, plus any proxy-configuration notice suppressing enforcement.

This does not establish resistance to rotating proxies, production conversion impact or a false-positive rate. The local checks use client-IP checkout history, so shared networks and IP rotation matter. Gateway fraud controls remain useful alongside application checks.

Try it

WebDecoy Bot Detection is on WordPress.org. Local protection works without a WebDecoy account. Update to 2.10.6 or newer before testing classic checkout.

Start in monitor mode, inspect the evidence, test your checkout in staging, and then review enforcement. The full test and rollout guide includes the setup and limitations.

Have you had a WooCommerce integration look enabled while its callbacks were missing? I would be interested in how you catch that in integration tests.

Written with AI assistance. Results come from the controlled tests described above.

AI crawlers found your site. Are they sending visitors back?

webdecoy — Wed, 21 Oct 2026 03:06:20 +0000

You can fix your sitemap, improve your headings, and make your content easier for machines to read. The next question is practical: are AI systems visiting, and are they sending people back?

We built a 35-second demonstration using our own site's data. I'm on the WebDecoy team; GEOMCP is our open-source audit project.

1. Start with a technical change you can verify

Use GEOMCP from your MCP-compatible editor to audit a public page and inspect the evidence behind each finding. A useful starting prompt is:

Audit https://your-site.example. Show the three most useful fixes and the evidence for each. Recheck the affected pages after the changes.

In our recorded October 17 audit, we checked 193 sitemap URLs and cleared 11 original warnings. One small example was the features page: 16 links, including one empty or generic label, became 16 links with no empty or generic labels.

That is a verified technical improvement. Keep the audit output and the deployment date so you have a concrete change to compare against later.

2. Observe crawlers where their requests arrive

A browser analytics tag only sees visits that execute it. Many crawlers never run JavaScript, so use server or edge observation to see those requests.

In WebDecoy, select your property and open AI Traffic. Choose a time window, then inspect the crawler breakdown alongside the overview. Keep AI-only crawling separate from operators that serve both search and AI.

Our seven-day snapshot showed:

Measurement	Observed value
AI-only pages crawled	4,547
Additional mixed search + AI crawling	1,220
AI referral visits	7
Distinct referral landing pages	5

These are recorded counts for webdecoy.com, not a benchmark for every site. “Pages crawled” counts crawling activity; it does not mean 4,547 unique URLs.

3. Follow the return visits

Open Referrals to inspect both the referring platform and the landing page. In this snapshot, ChatGPT, Gemini and Kagi each sent two observed visits; Claude sent one.

The destination matters as much as the total. A tutorial or demo page receiving those visits gives you a specific page to improve: make its explanation clear, keep its example runnable, and give the reader an obvious next action.

Use the page tag or edge sensor to observe referral visits. A crawler request and a referred human visit are separate events. A page can also appear in an AI answer without anyone clicking it, and missing referrer information can leave a visit unattributed.

4. Build a repeatable comparison

Record the deployment date and affected URLs. Compare equal time windows and check the sensor coverage. Look at which pages are crawled, which platforms return visitors, and which pages those visitors land on. Measure your own signup or activation events separately if you want to understand what happens after arrival.

Our audit and these traffic observations do not establish that a technical fix caused a referral. They give us a way to inspect both sides of the loop and decide where to work next.

Try the GEOMCP setup and recorded audit, then connect your site to WebDecoy and inspect AI Traffic → Referrals.

Which part is hardest to measure on your site today: the crawl, the referring platform, or what visitors do after they arrive?

Bot su WordPress: cosa vede il plugin quando c’è una cache davanti?

webdecoy — Tue, 20 Oct 2026 23:19:35 +0000

Hai installato un plugin per rilevare i bot, ma il registro non mostra tutte le visite? Prima di cambiare le soglie, controlla dove viene servita la pagina.

Una CDN o una cache può rispondere senza eseguire WordPress. In quel caso, il codice PHP del plugin non vede quella richiesta alla pagina. Questo dettaglio cambia il modo in cui interpreti i risultati.

Faccio parte del team WebDecoy. Qui uso il nostro plugin libero per WordPress come esempio concreto. Il testo italiano è stato preparato con assistenza IA.

Guarda il registro cambiare in 20 secondi

Nel video, una richiesta controllata al canary produce due rilevazioni nel registro locale di WordPress. La modalità monitor registra senza bloccare. È una prova del percorso di rilevazione, non un benchmark della cache: le verifiche con cache attiva restano da eseguire sul proprio sito. Il video contiene testo in inglese.

Prepara una prova ripetibile

Usa un sito di staging, con una pagina pubblica e un modulo nativo di WordPress. Annota URL, ora del test e configurazione della cache. Non usare dati reali dei clienti.

Installa WebDecoy dal catalogo di WordPress oppure con WP-CLI:

wp plugin install webdecoy --activate
wp webdecoy config set mode monitor
wp webdecoy status

La modalità monitor registra le rilevazioni senza bloccare le richieste. Il funzionamento locale non richiede account o chiavi API; il collegamento a WebDecoy Cloud è facoltativo. Il plugin richiede WordPress 6.1 o successivo e PHP 7.4 o successivo.

Separa tre percorsi

Percorso	Cosa verificare
Pagina non servita dalla cache	La richiesta raggiunge WordPress? Quali eventi compaiono nel registro?
Stessa pagina servita dalla cache	Il server di origine viene contattato? Il codice del browser è ancora presente?
Invio del modulo	Quale endpoint riceve l’invio? Il controllo avviene anche se la pagina iniziale era in cache?

Non interpretare la mancanza di un evento come una prova di assenza di bot. Potrebbe mancare il segnale, oppure la richiesta potrebbe non aver raggiunto il componente che lo registra.

Controlla il modulo con un test controllato

Prima completa un percorso normale: commento, login o registrazione, se disponibile. Poi, solo sul sito di prova, individua un campo trappola effettivamente generato da WebDecoy ed esegui un invio controllato che lo compili.

Confronta ora, percorso ed evento nel registro. In modalità monitor stai verificando la rilevazione del segnale: non aspettarti un blocco.

Per un modulo di terze parti, controlla l’integrazione specifica. Il fatto che un plugin protegga i moduli nativi di WordPress non significa che intercetti automaticamente ogni endpoint REST o modulo personalizzato.

Non confondere una visita sospetta con un’identità

WebDecoy combina esche, analisi delle richieste e segnali del browser. Questi elementi aiutano a investigare l’automazione, ma non identificano da soli una persona o uno specifico agente IA.

Se il sito è dietro un proxy, controlla inoltre come viene determinato l’indirizzo del client. Una politica basata su un IP interpretato male può raggruppare visitatori diversi.

Nel registro locale puoi esportare gli eventi in CSV e configurare la conservazione, impostata a trenta giorni per default. Confronta i risultati con i tuoi log prima di scegliere una risposta più restrittiva.

Il risultato utile del test

Alla fine dovresti poter rispondere a tre domande:

Quali richieste arrivano davvero a WordPress?
Quali segnali restano disponibili con la cache attiva?
I percorsi legittimi continuano a funzionare?

Se non riesci a rispondere, raccogli prima queste prove. Cambiare una soglia non risolve un punto cieco nella raccolta dei segnali.

Puoi installare WebDecoy da WordPress.org e leggere il codice su GitHub. Se provi questa verifica con una cache particolare, indica nei commenti configurazione e passaggi riproducibili, senza pubblicare IP dei visitatori o log privati.

Catch WordPress bots without an account: a five-check WebDecoy setup

webdecoy — Tue, 20 Oct 2026 03:12:10 +0000

WebDecoy detects automated traffic in your WordPress dashboard and adds protection for comments, login, registration and WooCommerce checkout. The free plugin runs locally without an account or API key.

I’m on the WebDecoy team. This is a practical acceptance test for our free WordPress plugin, which runs locally without an account or API key. Start on staging, in monitor mode.

Install WebDecoy on your WordPress site. Enter your site URL to open plugin search in your own WordPress admin, then choose Install Now and Activate.

Watch the full install, detection and protection walkthrough

This 2:50 walkthrough installs WebDecoy from WordPress.org, inspects the detection log, reviews the default AI crawler policy, and enables protection. In the controlled local test, the exact canary returns HTTP 403 with enforcement, while an ordinary homepage request returns 200. Test requests are labeled; they are not customer attack statistics.

Full written installation guide.

1. Install, then confirm the mode

In wp-admin, open Plugins → Add New, search for WebDecoy, and install and activate it. The plugin author is WebDecoy. You can also use WP-CLI:

wp plugin install webdecoy --activate
wp webdecoy config set mode monitor
wp webdecoy config list
wp webdecoy status

Monitor mode records detections without enforcing blocks. Confirm the setting before testing. Keep a note of your existing security plugins and cache configuration so you know what else can affect a result.

2. Exercise a normal visitor journey

Use a private browser window. Try the WordPress flows your site actually uses: opening a page, submitting a legitimate comment, logging in and registering if registration is enabled.

On a WooCommerce staging store, use your payment provider’s sandbox to test checkout. Never use live card transactions to simulate an attack.

Record whether the action completed, what the visitor saw and whether WebDecoy logged anything. A clean-looking home page does not verify registration or checkout.

3. Verify a controlled detection

On a staging form protected by WebDecoy, inspect the actual rendered honeypot field. Make a controlled test submission that populates that field, then check the plugin’s local detection log.

Compare the event time and request path with your test. In monitor mode you are checking observation, not expecting enforcement. If the event is missing, investigate the form integration and request path before assuming protection.

Use the field your installation actually renders; do not copy a guessed field name. Third-party form builders need their own compatibility check.

4. Test through the cache and proxy

Repeat a normal page request with the cache cold and warm. Check your host or CDN’s response headers to establish which request was a cache hit.

A request served entirely by an edge cache may never reach WordPress PHP. Browser-side reporting and server-side inspection are separate paths; verify both. Also verify how the real client address is passed through your trusted proxy before relying on IP-based limits.

5. Decide from evidence

Keep a short test record:

Test	What to record
Normal visitor	Completed action and unexpected events
Controlled honeypot submission	Matching local detection
Cache hit and miss	Which layer observed each request
Sandbox checkout	Successful normal flow and relevant logs

If you have not observed the path you care about, keep investigating in monitor mode. If you later enable enforcement, rerun the legitimate flows immediately. A bot signal is useful evidence; it is not a guarantee that every automated request is malicious.

The core plugin includes local logs, comment/login/registration protections, honeypot signals and WooCommerce checkout features. Connecting WebDecoy Cloud is optional. You can evaluate local behavior without creating a cloud account.

Install WebDecoy from WordPress.org and try these checks on one site. If a step behaves differently on your stack, share the WordPress, PHP, form and cache versions and a sanitized description of the result. Do not post visitor IP addresses, credentials or private logs.

Prepared with AI assistance.

Catch WordPress bots without a CAPTCHA: a local-first WebDecoy rollout

webdecoy — Sun, 18 Oct 2026 20:58:06 +0000

Spam comments. Fake accounts. A checkout full of failed card attempts. Those are three different places to investigate, but none should require putting an image puzzle in front of every customer.

We built WebDecoy, a free WordPress.org plugin that combines server-side checks, browser signals and hidden decoys. Local detection works without a WebDecoy account or API key. Here is how to start using it on a site you manage.

Install and observe

In wp-admin, open Plugins → Add New, search for WebDecoy, install it and activate it. Or use WP-CLI:

wp plugin install webdecoy --activate
wp webdecoy config set mode monitor
wp webdecoy status

Monitor mode is the default. It records detections without blocking requests, so you can inspect the signals before enabling enforcement. Check the local detection log and statistics rather than assuming that activation means traffic is being blocked.

Match the protection to the problem

For comment spam and fake registrations, the plugin adds invisible honeypot fields to core WordPress forms and evaluates submission signals. Login protection also includes rate limiting for brute-force activity.

For WooCommerce card testing, it checks checkout velocity and patterns such as rapid attempts and repeated declines across multiple cards. Checkout limits are configurable, and the plugin supports both classic checkout and WooCommerce Blocks. A hidden decoy coupon adds another signal when automation discovers and applies it.

For scanners and scrapers, hidden paths, decoy links, fake-file responses with canary credentials and WordPress-specific traps give automated clients opportunities to reveal their behavior. Browser detection adds automation and behavioral signals when JavaScript executes.

These mechanisms serve different purposes. A browser signal and a server-side tripwire do not have the same coverage. Review the specific signal behind a detection before choosing your response.

Test the flows real visitors need

While monitoring, exercise the routes your site actually uses: a normal comment, a registration if enabled, a login, and a test checkout through your payment provider’s supported testing process. Include the devices, privacy tools and accessibility flows your customers use.

Review the detections alongside those actions. Adjust your settings and allowlist where appropriate, then enable enforcement when the behavior fits your site. Monitor-mode findings are observations, not a measured claim that attacks were blocked.

Useful for agencies, too

You can inspect available settings and status through WP-CLI:

wp webdecoy config list
wp webdecoy status

The plugin also supports deployment constants for a forced default mode, hiding its admin UI, limiting log retention and an emergency disable switch. That lets you keep the configuration in your deployment process instead of repeating every click across client sites.

Local plugin, optional cloud

Detection logs and statistics work in WordPress. The plugin’s listing documents no external connections until you deliberately connect WebDecoy Cloud. Cloud connection is optional and adds centralized reporting, reputation enrichment and integrations; review its data-sharing details before connecting.

The plugin runs within WordPress. If you need filtering before requests reach PHP, that requires a separately configured edge or firewall integration.

Start free

Install WebDecoy from WordPress.org.

Open your site’s plugin installer from our WordPress page.

Read the setup documentation.

I’m on the WebDecoy team. If you try it, tell us which signal helps explain the noise on your site: form submissions, scanner traps or checkout activity.

Shopify bot traffic: a practical investigation checklist before you block shoppers

webdecoy — Sun, 18 Oct 2026 19:32:25 +0000

A traffic spike with no sales is a reason to investigate. It is not, by itself, proof of bots. The useful question is: what did those sessions do, and did they connect to an order?

I’m on the WebDecoy team. We built a Shopify app for that investigation. This guide explains the workflow, including the limits that matter before you automate decisions.

1. Separate three different problems

Treat these as separate questions:

Suspicious browsing: repeated catalog requests, automation signals, or interactions with hidden decoys.
Checkout abuse: bursts of checkout or payment attempts that require payment-provider and Shopify investigation.
Order review: completed orders where you can correlate a storefront session with suspicious activity.

An order-review tool cannot retroactively prevent every failed payment attempt. Keep payment controls and detection evidence in their respective roles.

2. Verify your collection before interpreting a quiet dashboard

After installing WebDecoy, open your theme editor, go to App embeds, enable WebDecoy Bot Detection, and save. Then open Setup & health in the app.

Create a labeled storefront test, visit its link, and confirm delivery. Test detections stay out of normal traffic metrics and order review.

Check storefront delivery and checkout delivery separately. The storefront embed and checkout Web Pixel are different collection paths. A successful storefront test does not prove every checkout event is arriving.

3. Investigate the signals together

Look for a combination of evidence: browser automation indicators, behavioral patterns, request context, and decoy interactions. IP enrichment adds VPN, proxy, and data-center context.

A VPN is not a fraud verdict. A cloud IP is not proof that a purchase is unauthorized. Check whether the suspicious activity actually supports the action you are considering.

WebDecoy’s actor profiles can group related detections across sessions and IPs. That helps investigate repeat activity without treating every request as a completely separate visitor. Correlation is evidence to inspect, not proof of a person’s identity.

4. Bring the evidence into Shopify order review

For orders with a matching session and detection, inspect the score, signal breakdown, and available actor history. WebDecoy supports order tags, native Shopify risk assessments, and bot-score and risk-level metafields. Availability depends on your plan and configuration.

Use the Flagged Orders queue to record whether a reviewed order looks legitimate or suspicious and leave notes for the next person. A useful review record explains why you reached a decision.

The order-created handler does not independently stop checkout or cancel orders. Cancellation requires a separate Shopify Flow action in a workflow you configure and enable.

5. Automate the review process first

A sensible first workflow is:

Detect a correlated high-risk order.
Tag it for staff review.
Notify the responsible team.
Record the outcome before adding stronger actions.

Pro and Agency plans include Shopify Flow triggers. The downloadable review and notification templates start inactive so you can inspect their settings before enabling them.

6. Keep AI crawling and AI referrals separate

An AI crawler fetching product pages and a shopper arriving from an AI assistant answer different business questions. WebDecoy provides separate reports for observed crawler activity and identifiable AI referrals.

Referral counts are a floor: an assistant or browser can omit referral information. Robots.txt guidance expresses policy to cooperating crawlers; it does not enforce access against an uncooperative scraper.

Know the coverage limits

A browser embed cannot observe every scraper that fetches public HTML without running JavaScript or touching a decoy. Checkout pixel delivery can depend on consent and browser conditions. Order correlation needs a matching session and detection.

Use these limits when interpreting reports. A quiet dashboard is only meaningful after you have verified the collection path.

Try it on your store

WebDecoy is available on the Shopify App Store, with a Free plan. Install it, enable the app embed, and verify your first test detection before evaluating the data.

See the full Shopify capabilities and setup guide.

If you are investigating a traffic spike, which part is hardest to explain: the source of the visits, checkout activity, or the connection to orders? Please keep customer and payment information out of public comments.

We audited 193 pages with our open-source GEO MCP. Here is what it found.

webdecoy — Sun, 18 Oct 2026 03:12:10 +0000

We built GEOMCP, a free MIT-licensed MCP server for technical GEO and SEO checks. I’m on the WebDecoy team.

Then we ran it against all 193 URLs in our production sitemap through a real SDK client and stdio MCP server.

What needed attention

Five articles had unnamed checkboxes generated from Markdown task lists.
The glossary and bot report skipped a heading level.
Our Features page linked to AI Analytics with the label “Learn More.”
Three standalone pages had no contextual same-origin links in their main content.

We fixed the issues, deployed the changes, and ran the same MCP on those pages. All 11 original warnings cleared.

The run also found a bug in our comparison tool: it classified unchanged unknown results as coverage changes. We fixed that and added a regression test.

What the score does not tell you

182 pages initially scored 100 on the basic checklist. That does not establish AI citations, perfect accessibility, good Core Web Vitals, or higher conversion. The evidence behind each check is more useful than treating the score as a forecast.

GEOMCP has five read-only tools: audit a URL, audit supplied HTML offline, inspect robots policies, inspect a sitemap, and compare reports. No API key is required. It inspects server-delivered HTML and does not run page scripts.

See the real before/after results, the demo, and installation instructions.

Source and MIT license. Feedback and reproducible issues are welcome.

This write-up was prepared with AI assistance from recorded test output and reviewed against the implementation.

A bot-risk score is not an identity: designing order reviews in Shopify

webdecoy — Tue, 13 Oct 2026 03:57:09 +0000

A suspicious order arrives. Two visits share an IP address, an actor report shows several IPs, and the dashboard assigns a risk score. What should the reviewer actually conclude?

I’m Chris, founder of WebDecoy. Two questions on our Shopify launch discussion brought this into focus: what evidence survives a review, and how do you tell missing traffic from missing collection? Here is the distinction we use, including the limits of our current app.

1. Store observations separately from conclusions

Observation	What it does not establish by itself
Two requests used the same IP	That the same person made them, or that either request was abusive
A correlated actor used multiple IPs	The legal identity of a shopper, or fraud on every related order
An IP was classified as a VPN or proxy	That the customer intended abuse
A dashboard shows zero detections	That collection is healthy, or that no bots visited

Shared Wi-Fi and company networks are straightforward reasons to be careful with IP-based conclusions. Correlation is an investigation aid. It needs supporting session or fingerprint evidence, and a reviewer should inspect the connection to the particular order.

2. A decision log and an evidence snapshot solve different problems

In WebDecoy’s Shopify app, saving a review records the decision, note, staff ID, and timestamp in review history. Updating the current review does not replace those earlier history entries. The UI shows the latest 100 decisions for that order.

That is not a frozen snapshot of all detection evidence. Detection details and the actor’s current cross-IP information can be fetched separately. Looking at them later is not a guarantee that you are seeing precisely what the reviewer saw earlier.

For any review tool, label these views explicitly:

Decision history: what a reviewer recorded and when.
Order-linked evidence: which detection or session supported the association.
Current investigation context: related activity available now.
Evidence snapshot: a preserved version of the evidence at decision time, if your tool actually implements one.

WebDecoy currently implements the review history, but not that full evidence snapshot. Do not turn a saved note into a claim of complete historical reproducibility.

3. Keep concurrent reviews from silently overwriting each other

A useful implementation pattern is an optimistic version check. Our review save path validates the submitted version, updates the current decision only when that version still matches, and inserts the history event in the same database transaction.

Conceptually:

begin transaction
  update current review where version = submitted version
  if no row changed: reject as a conflicting review
  append decision + note + reviewer + timestamp
commit

The reviewer receives a reload message when another staff member has changed the record. This protects the review workflow from a lost update. It still does not preserve the entire detection screen: that requires a separate evidence-versioning design.

Keep customer and payment details out of free-text notes. Our review UI asks reviewers to avoid them.

4. Verify collection before interpreting an empty report

WebDecoy’s Setup & health page separates Storefront and Checkout pixel delivery. Each has a last-success timestamp and a last-error timestamp. A missing timestamp appears as Not yet observed.

For storefront collection:

Enable and save the WebDecoy Bot Detection app embed on the published theme.
Open Setup & health and choose Create test.
Open the generated storefront test link, unlocking a password-protected store if needed.
Return and look for Test detection received. Storefront collection verified.

The test verifies the storefront path; it does not verify checkout-pixel delivery. Test detections are labeled and excluded from traffic metrics, order review, and enforcement.

Checkout monitoring is separate. A connected pixel with no events is not proof of failure; event delivery can depend on customer consent. Likewise, the absence of a detection is not proof that every scraper was stopped. A client that neither executes JavaScript nor touches a decoy may not appear in the storefront report.

5. Make the response a deliberate step

In WebDecoy, saving a review records an assessment. Fulfillment actions remain in Shopify. The app’s order-created handler does not independently cancel an order or block checkout. Cancellation requires a separate merchant-configured and enabled Shopify Flow action.

The useful workflow is: verify collection, inspect the order-linked signals, record the reasoning, then choose the response.

See the workflow

Watch the short Shopify demo and setup walkthrough. The demo uses a test store and seeded data, not customer results. WebDecoy is listed on the Shopify App Store.

AI assisted with drafting; implementation claims were checked against the current app code. This is a workflow example, not a fraud-detection accuracy benchmark.

Put a check in front of your model before it runs (WebDecoy AI Protection is in beta)

webdecoy — Fri, 09 Oct 2026 00:30:07 +0000

Your AI endpoint is probably the most expensive route in your app. Every request to /api/chat turns into tokens you pay for, and every MCP tool call can read your database, export records or kick off work in another system.

Most apps protect these routes the same way they protect everything else: authentication, then a rate limit that counts requests. That works until someone signs up, gets a valid session, and points a script at your chat route. Or until an agent with a perfectly valid token calls your documents.export tool sixty times in a minute. Request counts treat a one-row search and a full export as the same thing.

We built AI Protection for that gap, and it is now in public beta.

What it is

AI Protection is a set of server-side SDKs you install in your own backend. They sit inside your route, after your authentication and input validation and immediately before the model or tool runs. The rule is simple: if a request is denied, the model or tool never starts.

Node.js / Next.js, Go and Python (FastAPI) SDKs for request admission, plus an experimental Cloudflare Workers adapter
A Node MCP adapter for Streamable HTTP tool servers
A dashboard where you see decisions, model attempts, tools and individual callers, and can pause a caller or a tool

The SDKs are public and Apache-2.0: Node, Go, Python.

Protecting a chat route (Node)

Create the instance once in a server-only module:

import { createAIProtection } from '@webdecoy/ai-protection';

const protect = createAIProtection({
  webdecoyUrl: process.env.WEBDECOY_URL!,
  webdecoyKey: process.env.WEBDECOY_KEY!,
  propertyId: process.env.WEBDECOY_PROPERTY_ID!,
  subjectSecret: process.env.WEBDECOY_SUBJECT_SECRET!, // random, 32+ characters
  scopeId: 'support-chat',
  route: '/api/chat', // a fixed route template, never a raw URL
  protectionMode: 'observe',
  resolveClientIP: trustedClientIP, // your ingress decides which IP to trust
});

Then, inside your route, after auth and validation:

return protect(request, () => callYourModel(request.signal));

trustedClientIP and callYourModel are your code, not SDK exports. The callback returns a normal Response, and a streaming response passes through unchanged. Start in observe mode, look at what WebDecoy would have done, and switch to enforce when you trust it.

Protecting MCP tools

If your AI feature exposes tools over MCP, the adapter wraps each tool so every call is authenticated, validated and authorized by your code before it runs:

import { createProtectedMCPHandler } from '@webdecoy/ai-protection/mcp';

const handler = createProtectedMCPHandler({
  resource: 'https://api.example.com/mcp',
  authorizationServer: 'https://your-issuer.example.com/',
  policyVersion: 'records_v1',
  authenticate: (request, { signal }) => verifyAccessToken(request, { signal }),
  tools: {
    'records.read': {
      description: 'Read an owned record',
      inputSchema: {
        type: 'object',
        properties: { id: { type: 'string' } },
        required: ['id'],
        additionalProperties: false,
      },
      requiredScopes: ['records:read'],
      validate: (args) =>
        args !== null && typeof args === 'object' && !Array.isArray(args)
        && Object.keys(args).length === 1 && 'id' in args && typeof args.id === 'string',
      authorize: ({ caller, args }) => records.canRead(caller, args),
      execute: ({ caller, args, signal }) => records.readForTenant(caller.tenant, args, signal),
    },
  },
});

A few details we cared about:

Tool listing is filtered by scope, and every call checks scopes again. Naming a hidden tool directly does not get around it.
Tenant comes from your verified caller, never from tool arguments, so a forged tenant argument is rejected before your code runs.
Every tool result carries an action ID, and the dashboard can open that exact call.

Limits measured in work, not requests

A request counter cannot tell a one-row search from a full export. AI Protection can limit work: each tool declares a conservative maximum, the SDK reserves it across all your replicas before the call, and settles what your code actually did afterwards. Model budgets work the same way, reserving tokens before the provider call and settling confirmed usage.

You also pick what happens when WebDecoy is unreachable, per control. Fail open keeps serving with degraded coverage. Fail closed keeps a hard limit and refuses with a 503. Your own authorization rules apply either way.

Checking it without paying for a model

The part we are happiest with is the install doctor. From a checkout of the Node SDK:

git clone https://github.com/WebDecoy/ai-protection && cd ai-protection && npm ci
node scripts/doctor-mcp.mjs detect /path/to/your/app

detect reads your project (it never runs your code), tells you whether the layout is supported, and prints the exact setup commands with your files filled in. Each command has a plan mode that changes nothing, and a rollback.

Then doctor-mcp.mjs check plan.json runs your own synthetic calls against the running route: what should be allowed, what should be forbidden, what should be refused as cross-tenant, and what happens on cancellation. Add an outageRuntime and it serves a stand-in WebDecoy that returns 503 to everything, so you can see your fail-open and fail-closed choices actually behave. For model routes, checkModelProtection does the same against a stub provider that counts its calls. No paid model calls anywhere.

What gets sent, and what does not

The SDKs send request metadata (method, your route template, client IP, User-Agent, header names), pseudonymous caller identifiers hashed with a secret you hold, decisions and outcomes, MCP tool names and schema fingerprints, and token counts for budgets.

They do not send prompts, model responses, tool arguments, tool results, raw user identities or credentials. The pseudonymous identifiers are correlatable on purpose, so we do not call them anonymous.

What it is not

This is a beta, so here is the honest list:

It does not replace your authentication or authorization. It runs after them and relies on them.
It is not prompt-injection or output-safety protection. It checks who is calling and how much work they are allowed, not what the prompt says.
We have not published detection accuracy numbers. We will when there is real-world data behind them.
The MCP adapter is Node only for now. Go and Python cover request admission.
It requires a code change in your backend. There is no proxy you can drop in front.

Try it

Product page: webdecoy.com/product/ai-protection
Setup guide: docs.webdecoy.com/ai-protection/setup
Install: npm install @webdecoy/ai-protection, go get github.com/WebDecoy/ai-protection-go@v0.1.0-beta.0 or pip install webdecoy-ai-protection==0.1.0b1

Start in observe mode on a test route, run the doctor, and tell us what breaks. We are especially interested in hearing from anyone running MCP servers in production.

WebDecoy is now on Shopify: from bot signals to order review

webdecoy — Sat, 03 Oct 2026 03:45:04 +0000

WebDecoy is now approved and publicly listed on the Shopify App Store. We built the app to connect suspicious storefront activity with the work merchants already do: inspect traffic, investigate repeat activity, and review orders before fulfillment.

Disclosure: I’m the founder of WebDecoy. This post was prepared with AI assistance and checked against our published Shopify implementation and capability documentation.

New: full Shopify setup walkthrough

Follow the 2:55 walkthrough from the official listing to an enabled storefront embed, a received test detection, and the order-review screen.

Recorded in our development store. The app and embed were already installed. We created a fresh labeled setup test; example orders use seeded QA data. Synthetic narration. The test verifies collection, not real-world detection accuracy.

Open Setup & health → Open theme editor, enable WebDecoy Bot Detection under App embeds and save. Return, select Check again, then Create test. Open the test link within ten minutes and confirm Test detection received. If the store is password protected, unlock it and reopen the link. Checkout-pixel delivery remains a separate check.

Full written setup steps · Install from the Shopify App Store

From a visit to an order review

An IP address alone is a poor reason to reject an order. A VPN is context, not proof of fraud. We combine browser behavior, server-derived request signals, IP enrichment, and interactions with hidden honeypot links and fields to make suspicious activity reviewable.

The integration has three distinct paths:

Storefront: a Theme App Extension supplies the app embed. Enable WebDecoy Bot Detection in the theme editor and save; there is no script to paste into theme files.
Checkout: a separate Web Pixel reports supported checkout-funnel events. The theme embed does not run inside Shopify-hosted checkout.
Orders: the storefront writes a session reference into the cart. When an order is created, matching detections and available actor context can contribute to its risk evidence.

Keeping those paths separate matters. A successful storefront test does not prove that checkout-pixel events arrive, and an order without the relevant session data cannot acquire a reliable browsing history just because the app is installed.

What merchants can inspect

Detection details show scores and supporting signals. Actor profiles group related activity using available fingerprint and session evidence, helping investigate repeat visits across IPs. These are investigative groupings, not guarantees of one unique person.

Flagged Orders provides a review queue with status and notes. Supported plans add order tagging, native Shopify risk assessments with facts, and Shopify Flow triggers. The app also supplies order-risk metafields and an order-details extension.

AI Crawlers and AI Referrals are separate reports: catalog retrieval and a shopper arriving from an AI assistant are different events. Referrals depend on identifiable source information; missing referrers cannot be reconstructed.

Verify collection before enabling a response

After installation:

Choose a plan through Shopify and enable the theme app embed.
Open Setup & health, create a labeled storefront test, visit its link, and confirm that the detection arrived.
Check checkout-pixel delivery separately, accounting for consent and browser conditions.
Review detections and correlated orders before adding automation.

Test detections are excluded from traffic metrics, order review, and enforcement. Setup checks should not become fake threats in production reports.

Pro and Agency include Shopify Flow triggers. Our downloadable review and staff-notification templates start inactive when imported. Review the settings and enable them for new events when ready.

The order-created handler does not independently cancel orders or block checkout. Cancellation is a separate Flow action that a merchant must deliberately configure and enable.

What this can observe

A scraper that neither executes JavaScript nor touches a decoy can fetch public pages without appearing in storefront reports. This app does not deploy a WAF in front of Shopify-hosted checkout. We report the evidence our collection surfaces actually observe.

Try the Shopify app

The Free plan includes 500 detections per month. Starter is $59 USD/month, Pro $149, and Agency $449. Starter and Pro currently list 14-day trials; Shopify shows current pricing and trial availability before plan approval.

Watch the short demo and see the full setup guide. The demo uses a test store and seeded data, not customer results.

Install WebDecoy from the Shopify App Store.

What evidence would your team need before escalating an order for review?

What's calling your Fastify API?

webdecoy — Wed, 30 Sep 2026 18:49:00 +0000

A product endpoint can serve your frontend, a customer integration, and a scraper through the same URL. Your page analytics may only show the first of those.

Let's add request detection to a small Fastify API, watch a decoy request produce a verdict, and connect the results to a dashboard. We'll start in monitor mode so detection does not change the API's responses.

We build WebDecoy. This example uses its Fastify plugin and was prepared with AI assistance. It is request monitoring, separate from our FCaptcha project.

Build a small API

Use Node.js 22.12 or later. Create a folder and install the versions used here:

mkdir fastify-crawler-monitor
cd fastify-crawler-monitor
npm init -y
npm install --save-exact fastify@5.12.5 @webdecoy/fastify@0.18.3 @webdecoy/node@0.18.3

Create server.mjs:

import Fastify from 'fastify';
import webdecoy from '@webdecoy/fastify';
import { tripwire } from '@webdecoy/node';

const app = Fastify({ logger: false, trustProxy: false });
const apiKey = process.env.WEBDECOY_API_KEY || undefined;

await app.register(webdecoy, {
  apiKey,
  mode: 'monitor',
  honeytoken: false,
  skipPaths: ['/health'],
  rules: [tripwire({ paths: ['/.env'] })],
});

app.addHook('preHandler', async (request) => {
  const decision = request.webdecoyDecision;
  if (!decision) return;
  console.log({
    route: request.routeOptions.url,
    conclusion: decision.conclusion,
    tripwire: decision.deniedBy('tripwire'),
    dashboardConfigured: Boolean(apiKey),
  });
});

app.get('/health', async () => ({ ok: true }));
app.get('/api/products', async () => ({
  products: [{ id: 1, name: 'Field notebook' }],
}));
app.get('/.env', async (_request, reply) =>
  reply.code(404).send({ error: 'Not found' })
);

await app.listen({ host: '127.0.0.1', port: 4310 });

Register WebDecoy before your routes and the hook that reads its decision. Fastify's hook documentation explains the lifecycle and scope.

The /.env handler returns a fixed 404. It never opens an environment file. We use a path that should not contain public application content to demonstrate a concrete rule.

Automatic HTML trap injection is disabled here with honeytoken: false. The sample is a JSON API, and we only need request observation for this walkthrough.

See a verdict while the API keeps responding

Start the server:

node server.mjs

From another terminal:

curl -i http://127.0.0.1:4310/api/products
curl -i http://127.0.0.1:4310/.env

The product request returns HTTP 200 and a small catalog. The decoy path returns HTTP 404, while the terminal records:

route: '/.env'
conclusion: 'DENY'
tripwire: true
dashboardConfigured: false

DENY is the rule verdict. Monitor mode lets the application continue, so the response is still the 404 defined by the handler. Seeing a refusal in the log does not mean the request was blocked.

The example only logs a route template and a few decision fields. It does not print request headers, query strings, bodies, IP addresses, or API keys.

Put the detections in a dashboard

The local tripwire works without an account. To collect cloud detections, create a WebDecoy account and create an API key for the site you want to observe.

Put the key in a local .env file:

WEBDECOY_API_KEY=your_api_key

Add .env to .gitignore. Keep the key on the server, including when you deploy. It does not belong in the frontend that calls this API.

Stop and restart the server with the file loaded:

node --env-file=.env server.mjs

Then send the reserved test request:

curl -i -A 'WebDecoy-Test/1.0' http://127.0.0.1:4310/api/products

Open Detections in WebDecoy and look for the labeled Test record. The endpoint should still return its catalog. The record verifies reporting; it does not represent an actual AI agent visiting your API.

dashboardConfigured: true only means the process received a key. It does not prove the key is valid or the report arrived. If the record is missing, check the selected site, the key, outbound connectivity, and reporting errors.

Move it into your application

Keep your existing authentication, validation, authorization, and handlers. Add the plugin before the routes you want covered rather than replacing your server with this demo.

The demo binds to loopback and trusts no proxy headers. For deployment, configure trusted proxies for your actual network using the SDK's proxy settings. Do not trust arbitrary forwarded IP headers. Otherwise the traffic you are reviewing can be attributed to the wrong client.

This plugin uses preHandler. Requests rejected earlier in Fastify's lifecycle may never reach it. Likewise, requests served entirely by an upstream CDN do not reach this Node process. Use edge collection or access logs for those parts of the traffic.

Work out which activity matters

After deploying, look at the paths, repeated requests, classification, and supporting signals. A client using a familiar AI crawler name is not automatically that company's crawler. A legitimate customer integration is automated too, which is one reason to observe before enforcing a policy.

Detections are not a complete request counter. Some requests can be allowed locally without cloud reporting, and caching can affect reporting frequency. Keep access logs for overall volume.

Start with one useful question: which automated clients are repeatedly requesting the content this API exposes? Once you can answer that, you have a better basis for deciding what to allow, limit, or investigate.

What we checked

The example was tested locally on Node.js 26.5.0 with Fastify 5.12.5 and WebDecoy packages 0.18.3. Checks covered the catalog response, the tripwire verdict with its unchanged 404, the skipped health route, and the reserved test request in monitor mode.

No API key was used in those checks. Cloud delivery and real-crawler identification are not claimed as local test results.