> For the complete documentation index, see [llms.txt](https://documentation.pushly.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.pushly.com/platform/notifications/duplicate-send-check.md). # Duplicate Send Check Get warned before sending a notification that points at a page you have already sent ### Duplicate Send Check The **Duplicate Send Check** warns you when a notification you are about to send points at the same landing URL as a notification you have recently sent. It appears as a step in the **Delivery Confirmations** modal before the notification goes out. The check is **advisory, not a hard gate**. If a possible duplicate is found, you are warned before sending but can always choose to proceed. #### How It Works When you save or schedule a notification, Pushly compares its Landing URL against the Landing URLs of your recent sends within the same audience. If a match is found, a warning step is added to the **Delivery Confirmations** modal listing each matching notification with: * The notification title * Its notification ID * When it was or will be delivered * Its Landing URL, so you can tell a genuine duplicate from a false match You can acknowledge the warning and proceed — the check is non-blocking and advisory only. #### Match Modes How strictly two URLs must agree before they count as the same page is configurable per domain.
ModeTwo URLs are the same page when
The entire URL matches
(default)		They are identical. Capitalization of the scheme and host is ignored, as is a default port (:80 on http, :443 on https). Everything after the host is compared exactly, including capitalization.
The URL matches, ignoring tracking parametersThey point at the same page once tracking parameters, their ordering, a trailing slash and an anchor are all set aside.
**Why capitalization of the path matters.** `/Article` and `/article` can be genuinely different pages on the same site, so the path, query and anchor are always compared with their capitalization intact. Only the scheme and host are treated as case-insensitive. #### Ignoring Tracking Parameters If you append campaign or attribution parameters to your Landing URLs — or your RSS feed links carry them — the same article sent twice produces two URLs that differ only after the `?`. In the default mode those are two different pages, so the duplicate is not caught. Switching the domain to **the URL matches, ignoring tracking parameters** treats all of these as duplicates of a previously sent `https://example.com/article`:
URL you are about to sendWhy it matches
https://example.com/article?utm_source=push&utm_medium=webTracking parameters ignored
https://example.com/article?cm_ven=newsletterAll parameters are ignored, not just UTMs
https://example.com/article/Trailing slash ignored
https://example.com/article#topAnchor ignored
https://EXAMPLE.com/articleHost capitalization ignored
Parameter order does not matter either — `?b=2&a=1` and `?a=1&b=2` are the same page. {% hint style="info" %} Notifications whose Landing URL contains a macro, such as `{{item.url}}`, are always compared as whole URLs regardless of the mode. A URL that is still a template has no meaningful simplified form to compare. {% endhint %} #### Significant Parameters Ignoring every query parameter is the right behavior for almost every site, but not for a site whose query string says **which page you are on**. The clearest example is a WordPress site using non-pretty permalinks, where every article is `https://example.com/?p=12345`. Ignore the parameters there and every article looks like the homepage, so every send after the first is flagged as a duplicate. **Significant Parameters** is the exception list. Name the parameters that change which page a URL points at, and those are kept while everything else is still ignored. With `p` listed as significant:
ComparisonResult
?p=1 against ?p=2Different pages — not flagged
?p=1&utm_source=push against ?p=1Same page — flagged as a duplicate
Things to know about the field: * It appears only when the mode is set to ignore tracking parameters. * Enter the **parameter name only**, not a value — `p`, not `p=12345`. * Names are **case sensitive**. `Campaign_Name` and `campaign_name` are different parameters. * Bracketed names such as `ids[]` or `filter[status]` are accepted. * Up to 50 parameters, each up to 128 characters. A name cannot contain spaces or the characters `&`, `=` or `#`, because such a name could never match a real parameter. * Left empty — the default — every query parameter is ignored. #### Enabling the Duplicate Send Check The check is configured per domain. 1. Navigate to **Domain Settings → Notifications → General Settings**. 2. Click **Edit** and find the **Duplicate Checks** section. 3. Under **Duplicate Landing URL Check**, toggle the switch on or off. 4. Beside **Flag as duplicate when**, choose either **the entire URL matches** or **the URL matches, ignoring tracking parameters**. 5. If you chose to ignore tracking parameters and your site identifies pages by query parameter, list those parameter names under **Significant Parameters**. 6. Save your changes. The current state is shown in the **Duplicate Checks** section of the General Settings well as **Landing URL Check** — Enabled with the active mode, or Disabled — along with any Significant Parameters that are set. {% hint style="warning" %} **Before switching a domain to ignore tracking parameters:** if you send the same page repeatedly with a different campaign parameter each time — a daily forecast, a weekly digest, a re-engagement journey — those sends become the same page once tracking parameters are ignored, and they will be flagged as duplicates. That is intended, but it is a change in what you will be warned about. {% endhint %} #### Related * [Landing URL Validation](/platform/notifications/landing-url-validation.md) — a separate advisory check that verifies a Landing URL returns a healthy response before delivery --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://documentation.pushly.com/platform/notifications/duplicate-send-check.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.