A custom redirect domain lets you share a URL such as https://link.yourbrand.com/ABC1234567 beside the standard deeplinkify.eu version. Your domain performs one temporary redirect to the matching Deeplinkify path; Deeplinkify then records the eligible click and opens Amazon as usual.

Before you start: use a dedicated domain or subdomain

The safest option is a dedicated subdomain such as link.yourbrand.com, go.yourbrand.com, or shop.yourbrand.com. Do not install the wildcard redirect on your main website or its www folder: it would redirect every page on that site.

Your hosting provider must already serve the chosen domain over HTTPS with a valid SSL certificate. Deeplinkify does not take over its DNS or certificate.

1. Save the domain in Deeplinkify

Log in and open Custom domains.
Enter only the domain or subdomain, without https:// or a path.
Select Save custom domain.

The status is yellow and marked Pending verification. Deeplinkify will not present branded URLs as active until the redirect passes the configuration test.

2. Recommended setup: Apache .htaccess

Apache is common on shared hosting and is usually the simplest option.

If the dedicated domain folder has no existing .htaccess:

Select Download .htaccess ZIP in Deeplinkify.
Extract the ZIP. The file inside is named exactly .htaccess.
Upload that file to the document root of the dedicated redirect domain.

Files beginning with a dot are hidden by default on macOS. In Finder, press ⌘ ⇧ . to show or hide them.

If an .htaccess already exists: do not replace or delete it. Download a backup, copy the marked Deeplinkify block from the dashboard, and merge that block after the existing RewriteEngine On line but before WordPress or framework catch-all rules. Keep only one RewriteEngine On.

Alternative: Nginx or a hosting-provider rule

For Nginx, the equivalent temporary redirect is:

return 302 https://deeplinkify.eu$request_uri;

In a hosting panel or CDN, configure a wildcard source such as /*, send it to https://deeplinkify.eu/$1, and preserve the complete query string. Use HTTP 302 or 307 while configuring and in normal use.

Avoid HTTP 301. Browsers and messaging apps may cache permanent redirects for a long time, making mistakes and future changes difficult to undo.

Fallback: one redirect per link

If the provider cannot create wildcard redirects, you can create an individual 302 redirect for each short code. A static HTML file with a meta refresh may work for human visits, but it is less reliable for social previews and app-first opening, so use it only as a last resort.

3. Run the configuration test

Return to Custom domains and select Test configuration. The check verifies:

public DNS resolution;
a valid HTTPS certificate;
an HTTP 302 or 307 response;
preservation of the complete short-link path and query string.

The test uses a dedicated verification path and does not count as a link click. When it succeeds, the status changes to green Active.

What changes after verification

New and existing links show both a branded URL and the standard Deeplinkify URL. Bulk CSV exports add a custom_domain_deeplink column while retaining deeplinkify_deeplink. Both versions resolve to the same tracked link, destination, and analytics.

Troubleshooting

DNS not found: create or correct the domain record and allow time for propagation.
Secure connection failed: activate SSL for the dedicated domain before testing again.
Wrong response status: confirm the rule is active in the correct document root and returns 302 or 307.
Path or query missing: move the Deeplinkify rule before catch-all rules and preserve the original request URI.
Main website redirects unexpectedly: remove the rule immediately and install it only in the dedicated subdomain folder.

Test before a campaign

Open a branded link on iPhone and Android, from the social app or messaging app where it will be shared. Confirm the destination, Amazon app opening, and social preview. Then check Deeplinkify analytics to confirm real clicks are reaching the same link.