CallRail Number Not Swapping on Your Website

If your website still shows the regular business number when you expect a CallRail tracking number, first confirm what should appear for that particular visit. A Google Ads visitor, a direct visitor and someone returning in an existing browser session are not interchangeable test cases.

Dynamic number insertion, or DNI, replaces a number on the page according to the configured tracking rules. Diagnose the exact page, visitor source and phone element before replacing scripts or changing live tracking numbers. A successful number swap does not, by itself, prove that a call was answered, attributed correctly or converted into a booked job.

Choose the right diagnostic branch

Start with the symptom you can actually observe.

Keep a working way for customers to reach your business while investigating. Do not deactivate numbers, replace every phone link or remove tracking from the entire site to test one symptom.

Define the expected source before testing

Ask the account owner which tracking number or website pool should apply to the affected landing page and visitor source. Write down the actual source rule and the full test URL, including its query parameters. Opening the homepage directly is not a reliable test of a number configured for paid-search visitors.

CallRail's manual procedure uses a fresh visitor session. A private window is an alternative to clearing normal browsing cookies, but all private windows must be closed between cases before opening a new one. Existing session history can change which source CallRail recognizes. Its documentation also provides a Google Ads simulation using ?gclid=test, without clicking a paid advertisement. Manual DNI testing.

Use the documented simulation only for the matching source rule and label it as test traffic. It does not establish real ad attribution. Record the site's existing consent choice and browser environment; do not bypass consent, security or privacy controls to force a passing result.

Distinguish a failed test from a failed page

CallRail's automated test examines one page, not the whole website, and checks the company's tracking numbers. A number marked "not found" is not necessarily a problem if that number should never appear on the page.

The vendor also documents automated-test false negatives for its WordPress plugin and AMP installations. Manually reproduce the expected visitor case instead of treating every warning as proof that the live number is broken. Testing dynamic number insertion.

A 403 response from the tester can mean that the test request was blocked. That does not establish that DNI is failing for visitors. Save the affected URL and error for the site's security owner; do not disable the firewall or remove access protection merely to clear the warning. CallRail's snippet-test 403 explanation.

Check the correct installation on the affected page

CallRail assigns a different snippet to each company in an account. Confirm the company, installation method and affected page together. The current installation guide requires coverage on the visitor's landing page and each relevant phone or form page. The same snippet supports call and form tracking; enabling both is not a reason to install it twice. Installing the JavaScript snippet.

Ask the website administrator to inspect the live published page, not only a saved tag-manager draft. If Google Tag Manager is the installation method, CallRail's instructions distinguish saving the tag from publishing it. CallRail with Google Tag Manager.

If the failure began after a website optimization change, record that change before adding another snippet. CallRail documents cases where optimization plugins prevent its script from loading. Have the administrator inspect the delivered page and apply a narrowly scoped correction if that is the observed cause. Avoid switching off every plugin as a troubleshooting shortcut. DNI and caching plugins.

Match the swap target and preserve intentional exclusions

The swap target is the original number CallRail is configured to find and replace. Compare that setting with the number actually present on the affected page, not with a number remembered from an old campaign. A mismatch prevents the intended swap. Checking the swap target.

The markup matters too. CallRail identifies split digits, including numbers broken across span tags, as a possible cause. Its formatting guidance also distinguishes supported formats and directs vanity-number cases to support. A number that looks correct in a screenshot can still have markup that prevents matching. Swap target formatting.

Before removing any exclusion, establish why it exists. CallRail supports data-calltrk-noswap to keep an element and its children unchanged, including an SMS link that should retain its intended destination. An intentional static number is not a defect. Preventing a number from swapping.

Compare the displayed number with the call link

Check the header, contact section and mobile call button separately. For each, record both the visible number and the destination in its tel: link, where present. This comparison does not require placing a call.

CallRail documents a difference between a button containing the swap target as text and an input button whose number is stored in its value attribute. The latter is not swapped by the documented method. Ask the developer to review the affected element rather than assuming every visually identical button has identical behavior. DNI button troubleshooting.

A number printed inside an image needs a separate image-swapping setup with prepared replacement images. Ordinary text swapping does not edit those pixels. CallRail describes supported image placements and requires an image for each tracking number used by that setup. Swapping phone numbers in images.

Keep these outcomes separate: correct text, correct call destination and a successfully handled call. Only mark the result you actually checked.

Investigate a different number before changing the pool

If a number changes but not to the expected one, inspect overlapping rules before diagnosing a failed script. CallRail gives source-tracking rules priority over website pools. Landing-page URL or parameter rules take priority over specific referrers, broader referrer groups and Always Swap rules. Swap precedence rules.

Ask the account owner to identify the winning rule for the specific visit. Do not deactivate an apparently conflicting number until its use in other campaigns, pages or published materials is understood.

Copy this page and phone element check

Use one record per affected page and element. Record approved static elements as "should remain unchanged" rather than treating them as failures.

For example, if the desktop header changes but the mobile footer does not, create separate records. Reinstalling the whole site's snippet would not establish why those two elements behave differently.

After one authorized correction, repeat the same visitor scenario and check an unaffected element as well. Record "not checked" for unverified results. Retain the prior setting so the administrator can reverse the change if it causes a new problem.

Escalate the unresolved case with precise evidence

Send official support the affected page, company reference, intended source rule, installation method, browser state and redacted observations from the worksheet. Include the difference between the automated result and the live page. Do not send passwords, API credentials, customer recordings or unrelated visitor data.

If number swapping works but the problem begins when a lead reaches Jobber, use our CallRail and Jobber handoff guide. Our CallRail review covers buying fit and evaluation limits, while CallRail versus Aircall separates attribution software from the phone-system decision.

Evidence and scope

Official documentation checked on October 15, 2026. The worksheet and diagnostic sequence are ServiceTech Signal's proposed checks, not results from a connected CallRail account. No calls were placed and no live tracking settings were changed for this article.