Documentation

Everything you need to set up PageShield, understand how protection works, and get the most out of your dashboard.

1. Getting started

What PageShield does

PageShield watches for copies of your store's pages. If someone clones one of your landing pages onto another domain, pixel for pixel, offer and all, PageShield notices the moment a visitor loads that cloned page, logs it to your dashboard, and can automatically send that visitor straight back to your real site before they ever place an order somewhere that isn't you.

It does two things, and you're in control of both:

Detect & alert, always on. Every clone visit is logged with the hostname, page URL, referrer and timestamp, and you get notified.
Redirect, optional, and fully configurable. You decide whether cloned traffic just gets logged (Monitor only) or actively sent back to you (Monitor + redirect), and exactly how that redirect behaves.

How to create your first protected profile

A protected profile is one protected domain, its own settings, its own protection code, its own detection history. Most stores only ever need one, but you can create more (limits depend on your plan, see Plans & features).

Open Protected profiles in the sidebar.
Click + Create profile in the top right. A form opens in a dialog with:
- Name (optional), a label for you, e.g. "Main store" or "US market".
- Protected domain, your real domain, e.g. mystore.com.
- Redirect URL, the exact page cloned visitors should land on, e.g. https://mystore.com.
Leave the redirect settings on their defaults for now, you can fine-tune mode, trigger and percentage any time (see How protection works).
Click Create profile. The dialog closes and your new profile appears in the list.

If you don't have any protected profiles yet, the same "+ Create profile" action is also offered directly on the empty-state message.

How to install the protection code on your site

Once a profile exists, open it and click View code. You'll see one or two blocks to copy:

A <script> tag, always present, this is the main protection code.
An <img> tag, only if you've turned on the pixel fallback beacon for this profile (see Two detection layers).

Paste whatever you see there into the <head> of your site's HTML, as early as possible, right before the closing </head> tag:

<head> ...your existing tags... <script src="https://[your-snippet-domain]/s/[your-client-id].js" async></script> <img src="https://[your-snippet-domain]/api/v1/pixel.gif?c=[your-client-id]" style="display:none" width="1" height="1" alt="" onerror="this.onerror=null"> </head>

The exact tags, with your real domain and client ID already filled in, are what "View code" shows you. Don't type them by hand; copy them directly from the dashboard.

This works anywhere you can edit your theme's HTML or add "custom code"/head scripts: Shopify theme editor, WordPress, most page builders, or a hand-coded site. If your platform only offers a single "custom HTML" or "head injection" field, that's exactly where this goes.

You only paste this once. Any changes you make afterwards, redirect URL, mode, trigger, percentage, schedule, are pulled in automatically the next time the script loads. You never need to re-copy or re-paste the tag after editing settings in the dashboard.

How to confirm it's working

Go back to Protected profiles and look at the status badge next to your profile's name. The code checks in with PageShield ("a heartbeat") whenever someone loads your real protected page with it installed, so visit your own site once after pasting the code in, then refresh the dashboard.

● Live, the code is installed and has checked in within the last 24 hours. You're good.
● Not detected, no check-in has ever been received. Either the code isn't pasted in yet, or it hasn't loaded on a real page view.

This heartbeat is a separate signal from clone detection. It only confirms the code is running on your real domain, not that a clone has (or hasn't) been found. See the full status badge list in Protected profiles.

2. How protection works

Clone detection, simply

The code you paste in checks one thing every time it loads: is this the domain it was configured to protect?

If yes (a visitor is on your real site), it quietly checks in and does nothing else.
If no (it's running on some other domain, meaning your page's HTML, including this code, has been copied there), it logs a detection to your dashboard and, if you've turned redirect on, sends that visitor back to you.

That's the whole mechanism: your code only ever "notices" it's in the wrong place. It never has to guess or scan the internet for copies. The clone brings the detector with it, baked into the stolen HTML.

Two detection layers, and why having both matters

PageShield offers two independent ways to catch a clone:

Script beacon (the <script> tag), the main layer, present on every profile. Catches the vast majority of clones.
Pixel fallback beacon (the optional <img> tag, Pro/Business plans), a quiet backup. Some cloning tools deliberately strip out <script> tags when copying a page (to avoid pulling in tracking/analytics code they don't want) but leave ordinary <img> tags untouched. If that happens, the pixel is your only remaining signal, which is exactly why it's worth turning on.

Both layers report independently to your dashboard, and every detection is tagged via script or via pixel so you always know which one caught it. One important difference: an image can't run code, so the pixel can only detect and log. It can never redirect a visitor on its own. Redirecting always requires the script.

Pixel fallback is off by default even on eligible plans, turn it on per profile from Edit if you want the extra layer.

Redirect modes: Monitor only vs Monitor + redirect

Monitor only, clones are detected and logged, but visitors on the cloned page are left alone. Good for your first few days on a profile: see how often (and where) you're actually being cloned before you start actively redirecting their traffic.

Monitor + redirect, same detection and logging, plus visitors get sent back to your real site. This is what turns detection into an active countermeasure instead of just a log.

Redirect trigger: on page load vs on click

On page load, the redirect fires the instant the cloned page finishes loading, before the visitor really sees anything. The most protective option: almost no chance anyone experiences the clone's page at all. Good default for most stores.

On click, nothing happens until the visitor actually clicks somewhere on the cloned page, at which point they're sent to you instead of wherever that click was supposed to go. Useful when you want the clone's page to look completely normal for longer (an instant, jarring redirect can tip off whoever is running the clone that they've been caught), or when you specifically want to know that a real click happened, not just that the page loaded.

Redirect percentage: rolling out gradually

Instead of switching straight to redirecting 100% of clone visitors, you can start lower and increase it once you're confident everything behaves as expected.

Example: set the percentage to 25% on a new profile. For the first day, roughly 1 in 4 clone visitors get redirected; the rest are still detected and logged, just not redirected. Check Details & analytics. If the ratio looks right and nothing seems broken, raise it to 100%.

This is a per-visit dice roll, not a schedule, at 25%, every single visit independently has a 1-in-4 chance of being redirected, so short-term counts won't be exact, but they'll settle close to the percentage you set over enough visits.

Scheduled activation (Business plan)

Business profiles can set a future date and time at which redirect switches on automatically. Two common reasons to use it:

You've just found a clone and want to leave it running in Monitor-only a little longer to gather evidence, then have redirect kick in later without needing to be at your computer at the exact moment.
You want the switch to line up with something scheduled elsewhere (e.g. right when a competing ad campaign is expected to go live).

Until the scheduled time arrives, the profile behaves exactly like Monitor only, detections are logged, nothing is redirected.

3. Dashboard guide

Overview page

Your account's status at a glance, across every protected profile: total profiles, total detections, unread detections, and the same broken down over the last 24 hours / 7 days / 30 days. The Profile ranking card sorts your profiles by number of detections, so if you run more than one, you can see at a glance which one is being cloned the most.

Protected profiles: creating, editing, and status badges

Each profile card shows its protected domain, redirect URL, current settings summary, and two independent status signals:

Badge	What it means
● Live	Your real site has the code installed and checked in within the last 24 hours.
● Inactive	The code checked in before, but not in the last 24 hours. Not necessarily a problem yet, could just be low traffic.
● Not detected	No check-in has ever been received. The code likely isn't pasted in yet.
● Protection lost	The code was working before and has now gone silent for an extended period (48 hours by default), most likely it was removed during a theme update or redesign. You're notified once when this happens, and again when it recovers.

Click Edit on any profile to change its redirect URL, mode, trigger, percentage, schedule, or pixel fallback toggle, all changes apply automatically, no need to touch the code on your site again. Click Delete to remove a profile and its code entirely (this can't be undone).

Details & analytics: reading the charts and redirect stats

Click Details & analytics on a profile to open a full page dedicated to that one profile, filterable by Day / Week / Month / Custom range (the range picker at the top applies to the Activity and Traffic breakdown cards below):

Redirect performance card, a plain-language summary like "11 of 26 visits redirected (42%)", plus a breakdown of why the rest weren't: missed the percentage roll, monitor-only mode, scheduled activation not started yet, or (for click-triggered profiles) armed but the visitor hasn't clicked.
Detections chart, a bar per day/week/month, split into two colors: how many visits were redirected vs not, so trends are visible at a glance, not just totals.
Cloned domains table, every distinct hostname detected for this profile, with detection counts and first/last-seen dates.
Raw events table, every individual detection: date, hostname, detection method (script/pixel), a Redirected column (Yes / No / Pending / -), Location, Classification, referrer, and user agent.

The Redirected column can show four things: Yes (confirmed), No (didn't redirect, hover for the reason), Pending (click-triggered and armed, but no click confirmed yet, it could still turn into Yes), or - (not recorded, e.g. a pixel-only detection, which never has redirect capability).

Referrer and user agent are truncated in the table to keep rows readable, click either cell to open a dialog with the full, untruncated value and a Copy button.

Location and Classification, and what they actually mean: Location is an approximate country and city, derived locally from the visitor's IP address using an offline lookup database, PageShield never sends your visitors' IP addresses to any third party, and the raw IP itself is never stored, only this derived, approximate location. Classification is a best-effort Bot / Human / Unknown label based on the browser's user-agent string and whether the visit came from a known cloud/hosting network, it's a heuristic, not a certain determination, a real visitor on a VPN or a legitimate crawler can occasionally show as "Bot." See the Privacy Policy for the full technical explanation.

Traffic breakdown

On the same profile detail page, below Activity, for the same selected date range (Pro/Business plans):

Top countries, up to 10, ranked by number of detections.
Classification, the Bot / Human / Unknown split for this profile and range.
Top traffic sources, where cloned-page visitors came from, grouped into recognizable categories (Google, Facebook, Instagram, TikTok, Twitter/X, YouTube, Bing, Direct/None, or Other) from the existing referrer field.
Devices (Desktop / Mobile / Tablet / Unknown) and Browsers (Chrome, Safari, Firefox, Edge, Opera, or Other), parsed from the existing user-agent field.

All of this is computed from data already collected for detection purposes, country/city, classification, referrer and user agent, nothing new is collected for this view.

Notification suppression rules

If the same source keeps triggering repeat detections, e.g. a known crawler, a monitoring bot, or a specific visitor you've already investigated, you can stop getting notified about it without turning off detection or redirect protection:

In a profile's Raw events table, find a row from that source and click Suppress in the Actions column.
Confirm. Notifications from that same source, for this profile, are suppressed for 90 days.

What suppressing a source does, and doesn't, do: it only affects notifications. The detection is still recorded and visible in your dashboard exactly as before, and redirect protection is completely unaffected, a suppressed source's visitors still get redirected if your profile is set up to redirect. Only the "you've been notified about this" step is skipped. A rule automatically renews for another 90 days each time that source is detected again, so it stays quiet as long as the source keeps showing up, and expires on its own once it stops.

Active rules for a profile are listed in the Notification suppression rules card, further down the same page, with their status, when they were created, last matched, and when they expire. Click Remove on any rule to resume notifications from that source immediately.

Suppress is only available on detections recorded after this feature was released. Older detections in your history won't show the button, there's nothing retroactive to suppress from them.

Cloned domains

A single, sortable list of every foreign hostname any of your profiles has ever caught running your protection code, combined across all profiles, filterable to just one. Useful for a quick "who's cloning me overall" view without opening each profile individually.

Redirects log

The Redirects page in the sidebar is a focused log of only the visits that were actually sent back to you, "x-shop.com was cloned as y-shop.com, redirected to x-shop.com/product," filterable by profile and by Day / Week / Month / Custom range. It also shows your current redirect configuration per profile at a glance. Use this when you specifically want to know "who got redirected and where," rather than every detection including ones that weren't redirected, that's what the Detections feed and a profile's Raw events table are for.

Notifications

In-app messages appear here whenever something needs your attention:

A new clone was detected (a short "teaser", see below), sent at most once every 5 minutes per account, so a burst of clone traffic doesn't flood you, unless that source has been suppressed (see Notification suppression rules).
A profile's protection was lost, or recovered (see the status badge table above).
Occasional messages from the PageShield team.

Why notifications are deliberately vague: a detection notification never names the cloned domain. It just tells you something happened. Full details (which domain, which page, when) only ever live inside your dashboard. That way a notification showing up somewhere less private (an email preview, a Slack channel) never leaks which competitor or copycat is involved.

CSV export

Available from Export CSV (this profile) in a profile's Details & analytics, or Export CSV (all profiles) on the Overview page (Pro/Business plans). Each row is one detection, with these columns:

timestamp, profile_name, profile_origin_domain, cloned_hostname, url, referrer, user_agent, detection_method, was_redirected, redirect_skip_reason, country, city, classification

The export respects whatever date range you have selected on screen at the time.

A separate Export CSV button next to Notification suppression rules exports that profile's rules instead, one row per rule:

rule_id, profile_name, profile_origin_domain, status, created_at, last_matched_at, expires_at

rule_id is a plain reference id for the row, not a secret and not reversible to any visitor's IP address.

Account settings

From Settings in the sidebar:

Webhook alerts, see Alerts & webhooks.
Change password, requires your current password. Changing it signs out every other active session, this device stays signed in.
Contract withdrawal, a separate, formal action from cancelling a subscription, records your statutory withdrawal statement and emails you a dated confirmation.
Danger zone, permanently delete your account, every protected profile, and all detection data. Requires typing your account email to confirm. This can't be undone.

4. Plans & features

What you get on each plan:

Feature	Starter ($9/mo)	Pro ($29/mo)	Business ($79/mo)
Protected profiles	1	Up to 5	Unlimited
Dashboard history window^*	7 days	90 days	Unlimited while active
Real-time detection & alerts	✓	✓	✓
Redirect on page load, 100%	✓	✓	✓
Monitor-only mode, click trigger & redirect percentage	✕	✓	✓
Scheduled activation	✕	✕	✓
Pixel fallback beacon	✕	✓	✓
Analytics charts, Traffic breakdown & profile comparison	✕	✓	✓
CSV export	✕	✓	✓
Webhook alerts	✕	✓	✓
Priority support	✕	✕	✓

^*This is what your dashboard shows you, a separate, plan-independent data retention schedule applies underneath it on top: full detection detail (including approximate location and classification) is kept for 90 days regardless of plan, after that, anything that could identify or single out an individual visitor is deleted or irreversibly anonymised, the detection count and cloned hostname itself remain visible either way. See the Privacy Policy for the complete schedule.

How to upgrade

Any locked feature you come across in the dashboard shows an "Upgrade to …" link right next to it, or you can go straight to the Upgrade page from your trial banner (if you're on a trial). Pick a plan, checkout opens in a new tab through Lemon Squeezy, your card details never touch PageShield's own servers, and the change takes effect immediately, no waiting.

5. Alerts & webhooks (Pro/Business)

On top of in-app notifications, Pro and Business accounts can point PageShield at their own webhook URL, a destination that receives a small JSON message any time something worth knowing happens. Point it at an automation tool (n8n, Zapier, Make) or a chat app's incoming webhook (Slack, Discord) to get alerts wherever your team already looks.

Setting up your webhook URL

Go to Settings in the sidebar.
Under "Webhook alerts", paste your destination URL.
Click Save.

This is set per account, not per profile. One webhook URL receives alerts for all of your protected profiles.

What triggers a webhook

Clone detected, a short teaser, sent at most once every 5 minutes per account (so a burst of clone traffic sends one alert, not a hundred).
Protection lost, a profile that was checking in has gone silent for an extended period.
Protection recovered, that same profile has started checking in again.

What the payload looks like

Every event is a single POST request with a small JSON body:

{ "event": "suspicious_activity_detected", "message": "We detected suspicious activity on one of your protected pages. Check your dashboard for details.", "timestamp": "2026-07-08T14:32:10.000Z" }

protection_lost and protection_recovered use the same shape, with a message describing which profile and what happened. As with in-app notifications, the payload deliberately never includes which domain cloned you. That detail stays inside your dashboard.

6. Troubleshooting / FAQ

Why does my protection show as "Not detected"?

This means PageShield has never received a check-in from your real site. Double-check that the <script> tag from "View code" is actually pasted into the <head> of the live version of your site (not a draft or unpublished theme), then visit your own site once. The badge updates the next time you reload the dashboard. If you're using a page builder, make sure the code was added to a "custom code"/head field that actually renders on the published page, not just the editor preview.

Why didn't my site update after I changed redirect settings?

Give it a few minutes. The protection script loads its configuration live rather than being baked in, but that configuration is cached for about 5 minutes to keep things fast for your visitors, so a setting you just changed can take up to ~5 minutes to show up on a live page. If you're testing immediately after a change, try a hard refresh, and make sure you're testing on a page with a different hostname than your protected domain (the code intentionally does nothing but check in when it detects it's running on your real site, see Clone detection, simply).

Can someone tell my site is protected by looking at the code?

We've deliberately made this hard to spot. The script and pixel tags load from a separate, neutral-sounding domain, never from anything that says "pageshield", and the JavaScript itself is obfuscated before it's served, so it doesn't read like a readable, labeled "anti-clone script" in your page source. It isn't literally invisible to someone determined to reverse-engineer it, but there's nothing in the page that names PageShield or spells out what the code does.

What happens if I downgrade my plan?

Nothing is deleted. Your existing profiles and their full detection history stay exactly as they are. What changes:

You can't create new profiles beyond your new plan's limit until you're back under it. Profiles you already have keep working.
Any profile using a feature your new plan doesn't include (monitor-only mode, click trigger, a percentage below 100%, a schedule, pixel fallback) automatically falls back to the safest default, redirect on page load, 100% of visitors, no schedule, so protection never silently breaks, it just simplifies.
Analytics charts, Traffic breakdown, CSV export and webhook alerts stop being available, and only detections within your new plan's history window are shown, until you upgrade again. Older data isn't deleted, just out of view.

Why don't some of my older detections show a country, city, or a Bot/Human/Unknown label?

These fields were added after some of your detection history was already recorded, rows from before that don't have them and show as "-". Every new detection has them going forward, when a location or classification can be determined at all (see the callout in Details & analytics for why that isn't always possible).

Why doesn't a detection have a "Suppress" button?

Same reason as above, that button needs a small piece of data computed at the moment the detection was recorded. Detections from before Notification suppression rules existed don't have it, and can't be suppressed retroactively. Any new detection should have it.