SEO During Deep Link Platform Migration

Switching deep link platforms is a technical project. Switching deep link platforms without losing search rankings is a different project entirely. Your deep link URLs appear in sitemaps, structured data, internal links, and backlinks. Changing these URLs without proper redirects causes crawl errors, drops indexed pages, and breaks the connection between your web content and your app.

This guide covers how to handle the SEO side of a deep link platform migration. For the general migration process, see migrating to Tolinku. For domain migration specifically, see domain migration for deep links.

What Changes During a Deep Link Migration

URL Structure Changes

Most deep link migrations involve at least one of these URL changes:

Change Type	Before	After
Domain	`links.oldplatform.com/abc`	`links.yourapp.com/abc`
Path structure	`yourapp.com/l/product-123`	`yourapp.com/products/product-123`
Both	`oldplatform.app.link/xyz`	`links.yourapp.com/products/xyz`

Each change affects search engines differently. Domain changes are the most impactful because all link equity is tied to the domain.

What Search Engines Need to Reprocess

When your deep link URLs change, Google and Apple need to:

Re-crawl all pages that reference the old URLs (internal links, structured data, sitemaps).
Follow redirects from old URLs to new URLs.
Transfer link equity from old URLs to new URLs (this takes weeks).
Re-verify App Links (Android) and Universal Links (iOS) on the new domain.
Update the index with the new URL structure.

Pre-Migration SEO Audit

Inventory Your Indexed URLs

Before migrating, identify every URL that search engines know about:

Search Console: Export all indexed URLs from the Coverage report.
Sitemaps: List all URLs in your current sitemaps that contain deep link references.
Backlinks: Use a backlink checker to find external sites linking to your deep link URLs.
Internal links: Search your website content for references to your current deep link domain.
Structured data: Find all potentialAction targets, url fields, and target URLs in your JSON-LD.

# Find all internal references to the old deep link domain
grep -r "links.oldplatform.com" ./content/ ./templates/ ./components/
grep -r "oldplatform.app.link" ./content/ ./templates/ ./components/

Baseline Your Rankings

Record your current search performance before the migration:

Keyword rankings for all terms where deep link pages rank.
Organic traffic to pages that contain deep links.
Impressions and clicks from Search Console for affected URLs.
Core Web Vitals scores for key landing pages.

You will compare these numbers post-migration to detect regressions.

Redirect Strategy

301 Redirects (Not 302)

Use 301 (permanent) redirects, not 302 (temporary). Google treats 301 redirects as a signal to transfer link equity to the new URL. A 302 tells Google the old URL is still the canonical, which defeats the purpose.

# Nginx: redirect old deep link domain to new domain
server {
    server_name links.oldplatform.com;

    location / {
        return 301 https://links.yourapp.com$request_uri;
    }
}

Redirect Mapping

Create a complete redirect map before migrating:

# redirect-map.csv
old_url,new_url
https://links.oldplatform.com/product/123,https://links.yourapp.com/products/123
https://links.oldplatform.com/category/shoes,https://links.yourapp.com/categories/shoes
https://links.oldplatform.com/promo/summer,https://links.yourapp.com/campaigns/summer

For large sites, generate this programmatically:

const oldLinks = await getOldPlatformLinks(); // from old platform export
const redirectMap = oldLinks.map(link => ({
  old: link.url,
  new: buildNewUrl(link.path, link.metadata)
}));

Redirect Chain Prevention

Avoid redirect chains (old URL redirects to intermediate URL which redirects to final URL). Each hop in a redirect chain loses some link equity and slows crawling:

Bad:  old.com/abc → redirect-service.com/abc → new.com/abc  (2 hops)
Good: old.com/abc → new.com/abc  (1 hop)

If your old deep link platform already had redirects, ensure you map directly to the final destination URL.

Sitemap Updates

Timing

Update your sitemaps as part of the migration cutover:

Before migration: Sitemaps contain old URLs.
At cutover: Update sitemaps to contain new URLs only.
After migration: Submit updated sitemaps to Search Console.

Sitemap Structure for Deep Link Pages

Include xhtml:link annotations if your deep links have app-specific alternates:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://links.yourapp.com/products/123</loc>
    <lastmod>2026-06-18</lastmod>
    <changefreq>weekly</changefreq>
    <xhtml:link rel="alternate" href="android-app://com.yourapp/https/links.yourapp.com/products/123" />
  </url>
</urlset>

IndexNow

If your site supports IndexNow, submit the new URLs immediately after migration. This tells search engines to re-crawl the affected pages faster than waiting for the normal crawl cycle.

Structured Data Updates

Update All URL References

Search your structured data for any reference to the old deep link domain:

<!-- Before migration -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Running Shoes",
  "potentialAction": {
    "@type": "ViewAction",
    "target": "https://links.oldplatform.com/products/running-shoes"
  }
}
</script>

<!-- After migration -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Running Shoes",
  "potentialAction": {
    "@type": "ViewAction",
    "target": "https://links.yourapp.com/products/running-shoes"
  }
}
</script>

Verify with Rich Results Test

After updating structured data, test with Google's Rich Results Test to confirm the new URLs are valid and the structured data is still correct.

App Links and Universal Links Verification

Timeline Overlap

During migration, both old and new domains need to serve valid verification files:

Android: Both domains need valid /.well-known/assetlinks.json files.
iOS: Both domains need valid /.well-known/apple-app-site-association files.

Keep the old domain's verification files active for at least 30 days after migration. Google and Apple cache these files, and removing them too early can break app opening for users who have not updated their apps.

Verification File on New Domain

Ensure your new deep link domain serves the correct verification files before going live:

// /.well-known/assetlinks.json (Android)
[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.yourapp",
    "sha256_cert_fingerprints": ["YOUR_SHA256_FINGERPRINT"]
  }
}]

For verification file setup, see Tolinku deep linking docs.

Internal Link Updates

Find and Replace

Update all internal links across your site:

Blog posts referencing deep link URLs.
Navigation links.
Footer links.
Email templates.
Help center articles.
API documentation examples.

Smart Banner Updates

If you use smart banners, update the deep link URLs in your banner configuration. Smart banners that point to the old domain will still work if redirects are in place, but direct links to the new domain are faster and avoid the redirect hop.

Post-Migration Monitoring

Week 1

Check Search Console for crawl errors on the old domain.
Verify that 301 redirects are working (test a sample of old URLs).
Monitor organic traffic for any sudden drops.
Confirm that new URLs are being indexed (Search Console Coverage report).

Week 2-4

Compare keyword rankings to your pre-migration baseline.
Monitor the index status of new URLs (they should be growing).
Check for any remaining references to old URLs in Search Console.
Verify that backlinks are passing equity through redirects.

Month 2-3

Organic traffic should return to pre-migration levels (or improve if the new URL structure is better).
Old URLs should show as "Redirected" in Search Console, not "Not found."
New URLs should be fully indexed and ranking.

Tolinku Migration SEO

Tolinku supports custom domain deep links, which means your deep link URLs use your own domain (e.g., links.yourapp.com) rather than a third-party domain. This makes future migrations simpler because you control the domain and its redirects. Configure your domain in the Tolinku dashboard and set up verification files for both platforms.

For the complete migration process, see migrating to Tolinku. For the broader app indexing strategy, see app indexing and SEO for mobile apps.

Deep Linking Migration mobile-development redirects search-rankings SEO url-structure

Get deep linking tips in your inbox

One email per week. No spam.