The Redirect and 404 Audit Every Indian Site Needs After a Replatform
Replatforming is the single most reliable way to lose organic traffic in India, and it is almost never the new platform's fault. WordPress to Shopify, custom PHP to WordPress, Magento to Shopify — the pattern is identical. Traffic holds for a fortnight, then falls thirty to sixty percent over six weeks, and by the time anyone connects it to the launch the diagnosis is three months late.
The cause is nearly always the same: URLs changed and the redirect map was incomplete, wrong, or chained.
The four failure modes, in order of frequency
Blanket redirect to the homepage. Every old URL points at the root. It looks tidy, it returns 200, and it destroys every page-level ranking the site had. Google treats a redirect to an irrelevant page as a soft 404 and drops the old URL's equity entirely. This is the worst outcome and the most common one.
Redirect chains. Old URL redirects to an intermediate, which redirects to the new page, sometimes via a www or http hop. Each hop is a small loss and a crawl cost, and chains longer than three hops are frequently not followed at all.
Parameter and trailing-slash inconsistency. The new platform serves both /page and /page/, or both with and without a query string, and nothing canonicalises. Signals split across duplicates.
Whole sections quietly missing. The old site had 900 blog posts; the new one has 400 and nobody produced the list of the 500 that were dropped. Every one is a 404 with inbound links.
How to run the audit in an afternoon
Get the complete old URL list. Not the sitemap — the sitemap only had the pages someone remembered. Pull from Search Console's Pages report and Performance report (export every URL with impressions in the last sixteen months), your analytics landing-page report for the same window, and any server log you can get. Deduplicate.
Request every one of them and record the final destination. A simple script that follows redirects and reports the start URL, the number of hops and the final URL and status code. This one table is the audit.
Sort the table into four groups. Landing on a relevant new page in one hop: correct, ignore. Landing on the homepage: broken, needs a real target. Two or more hops: rewrite the rule to point directly at the final destination. Returning 404 or 410: either restore the page or map it to the closest relevant equivalent.
Decide honestly about the leftovers. Not every old URL deserves a redirect. A discontinued product with no traffic and no links can 410. But a page with inbound links or historical impressions should always land somewhere relevant, because that is where its accumulated authority goes.
Then check what Google thinks
Two Search Console reports tell you whether the fix landed. The Pages report's “Not found (404)” and “Page with redirect” buckets should shrink week over week. The Performance report filtered to the old URLs should go to zero impressions while the new ones pick them up. If old URLs still draw impressions two months after launch, the redirects are not being followed.
Resubmit the new sitemap, and ping IndexNow if the platform supports it, so Bing and Yandex pick up the change quickly rather than waiting to recrawl.
The preventable version
If a replatform is still ahead of you rather than behind you, the redirect map is built before launch, not after: export the old URL list, map every row to a new URL by hand, and treat any unmapped row as a launch blocker. It takes a day and it saves a quarter.
A fuller walkthrough of the technical checks that belong in this audit is here: https://deepbhardwaj.com/seo-expert-in-india/
Related: robots.txt, staging leaks and stray noindex — the monthly ten-minute audit