Web Development Company in Pune: Changing Your Domain Name or Moving to HTTPS Without Losing Google Rankings — A Redirect Map and Launch Checklist

Web Development Company in Pune: Changing Your Domain Name or Moving to HTTPS Without Losing Google Rankings — A Redirect Map and Launch Checklist

You can change your domain name, move to HTTPS or restructure your page addresses without losing your Google visibility, but only if every old address permanently redirects to its single best new equivalent, and you handle the move in a particular order. Google's own site-move documentation says that 301 and other permanent redirects do not cause PageRank loss, that the move is processed one address at a time, and that you should expect temporary ranking fluctuation while Google works through every old and new URL. The failure cases are well known: redirecting everything to the home page, leaving a development noindex in place, forgetting to re-verify Search Console, and changing the domain, the design and the content all in one weekend so that nobody can tell what caused a drop. This guide is for the owner of a business, clinic, school or non-profit in Pune or elsewhere in India who is about to rebrand, merge two sites or change a domain, and for the developer who will do the work. It gives the preparation order, how to build the redirect map, what to do on launch day, what to monitor and what to put in a contract.

We rely on Google Search Central's "Site moves with URL changes" documentation throughout. Where something is our own practice from building and maintaining websites, we say so. We cite no recovery times or traffic percentages, because Google gives none beyond "a few weeks or more" for medium-sized sites, and any more precise number would be invented.

Which kind of move are you doing?

Google's documentation covers moves where page URLs change: HTTP to HTTPS, a domain change or merger, and a change in URL paths. Moves where only the hosting changes and the URLs stay the same are covered separately, and are simpler. Identify yours:

• HTTP to HTTPS on the same domain. Every address changes its scheme.
• A domain change. For example, an old brand name to a new one, or .in to .com. Every address changes its host.
• A merger. Two sites become one, so many addresses are consolidated into fewer.
• A URL structure change. The domain stays, but paths change, as when a redesign replaces /services.php?id=4 with /services/seo/.
• A subdomain change. shop.example.com to store.example.com, or a subdomain folded into the main site.

They are the same discipline at different scales. The redirect map is needed for all of them. The Change of Address tool in Search Console is needed only for some, as explained below.

The six rules from Google that shape everything else

Google's guidance opens with general practice that we would put on the wall of any migration project.

1. Change one thing at a time. Google's example is to change the domain, then the layout, not both together. If rankings move after a combined change, you cannot tell which change caused it. Our judgement: this is the rule clients most often want to break, because a rebrand feels like one event. Resist it. Move first, redesign later, or the reverse.
2. Time it for a quieter period. Google suggests a seasonal dip in traffic. For a Pune school, that is not admissions season; for a retailer, it is not Diwali; for a non-profit, it is not the year-end giving window.
3. Expect temporary fluctuation. Google says medium-sized sites may take a few weeks or more for new URLs to appear in place of old ones, and larger sites take longer.
4. Permanent redirects do not lose link credit. Google says 301 and other permanent redirects do not cause PageRank loss.
5. Use Search Console and verify each property separately.
6. Be patient. Googlebot has to visit every old and new URL at least once, so the move is handled per URL, not as a single switch.

If the site is large and it is technically feasible, Google suggests splitting the move into sections and testing with a section that changes infrequently. Google adds that a single section is a useful test but does not fully represent a whole-site move. For a typical business site with a few dozen or a few hundred pages, moving all at once is normal.

Phase 1: Prepare the new site before anything goes live

Google's preparation list is long, and every item has caused a real problem somewhere. These are the ones to treat as gates.

Build the new site to the same structure unless you have decided to change it. Google suggests setting up the CMS, preferably the same as the old site, and importing the content. Transfer hosted images and downloads such as PDFs, because a migration that moves pages but strands the brochures leaves broken links on the pages that remain.

Handle HTTPS correctly. If the move involves HTTPS, configure the TLS certificates before launch, and confirm the new addresses load without browser warnings. Our guide to domains, DNS and SSL renewals explains who controls each record and what to check so that the certificate does not lapse after launch.

Set robots.txt to the intended rules. If you blocked crawling or used noindex while the new site was in development, which is sensible, prepare the exact list of changes needed at launch. Google lists leftover noindex rules and robots.txt blocks as one of the most common migration mistakes. A missing robots.txt should still return a 404 rather than an error page.

Return a real 404 or 410 for content you are deliberately deleting. Google says to return HTTP 404 or 410 for deleted or merged content that has no replacement.

Verify both old and new sites in Search Console. Google asks you to verify every variant, www and non-www, HTTP and HTTPS, and subdomains, and to make sure verification files, meta tags or analytics-based verification remain valid on the new site. Our guide to Search Console properties explains the property types.

Carry over old settings. Google says to review old Search Console settings and apply them to the new site, including leaving the crawl rate to Googlebot's own determination and re-uploading any disavow file. If you have never used a disavow file, you have nothing to carry over.

If you bought a used domain, check its history. Google advises checking a newly purchased domain for inherited manual actions and leftover URL removals, especially site-wide ones. A removal request left by the previous owner can hide your new pages.

Set up analytics on both sites. Google suggests considering a separate analytics profile for the new site so that old and new can be compared.

Check server capacity. Google notes that Googlebot crawls more heavily after a migration, so make sure hosting can cope, and tell the host if the site is large.

Phase 2: Build the redirect map

The redirect map is the core deliverable of the move. It is a table with one row per old address and one column for the new address, and it should be built by a person who understands both sites.

Collect every old URL

Google's list of sources is worth following literally: the XML sitemaps, Search Console's Links report, high-traffic pages from logs or analytics, CMS listings, and recent server logs. Include images, videos, JavaScript and CSS, because other sites may link directly to them. Our own habit, and not a Google instruction, is to add a crawl of the old site with a crawler tool, then merge it with the Search Console list, so that you catch pages that exist but are not in the sitemap and pages in the sitemap that no longer exist.

Do not skip the long tail. A page that gets two visits a month may have a backlink from a respected directory or a news article, and that link is worth keeping.

Map each old URL to the most relevant new URL

For each row, decide the destination:

• A direct equivalent exists. Redirect to it. The old /web-design-pune.html goes to /services/website-creation/.
• Several old pages were merged into one. Google says redirecting several pages to one consolidated new page is acceptable. Redirect each old page to the merged page.
• No equivalent exists. Return a 404 or 410, or if a closely related parent page exists, redirect to that. Do not invent a relevance.
• The page was thin or duplicated. Redirect to the page that now covers the topic, or retire it.

Avoid sending everything to the home page. Google's documentation warns that mass-redirecting to the home page can be treated as a soft 404. A visitor who clicked a result about "NGO website cost" and lands on a generic home page leaves, and Google may decide the redirect is not a real replacement. This is the single most common error in rushed small-business migrations.

Use one hop

Use server-side permanent redirects, 301 or 308, where possible. Client-side redirects are a last resort. Redirect directly from the old address to the final address. Google says Googlebot follows up to 10 hops, but advises redirecting to the final URL directly, and if that is not possible, keeping chains to about three hops and under five. In a move that also includes HTTP to HTTPS and www consolidation, chains form easily: http://www.old.com/page to https://www.old.com/page to https://old.com/page to https://new.com/page. Write the rules so that every variant of the old address goes straight to the final new one.

Keep the map as data

Google says to store the mapping in a database or in rewrite rules. A spreadsheet is fine for review, but the live rules should come from it mechanically, not by hand typing, so that a mistyped character does not produce a hundred broken redirects. Ask your developer how the rules will be generated and where they will be stored.

Update the new site's own signals

The documentation says to add a self-referencing rel="canonical" tag to each new URL, update hreflang annotations to the new URLs if you use them, update internal links so that they point to the new addresses rather than relying on redirects, and save a sitemap of the new URLs. Our article on canonical URLs and duplicate content explains why each page should name itself as the preferred version.

A worked example, illustrative only and not a client result. A Pune physiotherapy clinic changes from smilephysio.in to smilephysiotherapy.com. Its map has 38 rows. Thirty-one old pages have direct equivalents, four blog posts are merged into one guide, two old offer pages are retired and return 410, and one old PDF brochure is moved to the same filename on the new domain. Every row goes straight to its final destination in one hop, including the http:// and www variants of the old address. That table, not the new design, is what protects the clinic's search visibility.

Phase 3: Launch day

Google's "starting the move" steps give the order. Our commentary follows each.

1. Activate the redirects. Do it at the server or CDN level where possible.
2. Confirm that canonical tags point to the new URLs and remove any temporary noindex rules. This is the step most often forgotten. Check the live pages' source, not the staging copy.
3. Test the redirects. Use the URL Inspection tool for individual URLs and command-line tools or scripts for bulk testing. We would test every row of the map, not a sample, because a pattern error often affects only one section. Check that each returns a 301 or 308 and ends on a 200 page.
4. Use the Change of Address tool only for the cases it covers. Google says to use it for domain or subdomain changes, for example example.com to example.net or a.example.com to b.example.com. Do not use it for HTTP to HTTPS, for toggling www, or for path changes. For a domain migration, Google says to submit it for every verified variant of the old domain, including unused ones.
5. Submit the new sitemap in Search Console and remove the old one.
6. Tell your hosting provider to expect increased crawling if the site is large.

Phase 4: Update the places that link to you

Google's order is to update internal links first, then contact external sites that link to old URLs, prioritised by traffic, then update profile links on social platforms and ad campaigns. Add to that, from our own practice: your Google Business Profile website field, email signatures, invoices and quotation templates, WhatsApp Business profile, printed material and QR codes. A redirect handles the link, but it adds latency, and updating the source is cleaner.

If you run paid campaigns, check that final URLs and tracking parameters still work after the move. A redirect that strips tracking parameters will silently break attribution; our guide on UTM tracking and campaign naming explains what to preserve.

Phase 5: Monitor

Google lists the places to watch, and we would set a calendar reminder for each.

• The Sitemaps report. Old-URL sitemaps will show redirect warnings, which are expected. Over time, indexing of old URLs should fall while indexing of new URLs rises.
• The page indexing report. Watch for crawl errors and the expected shift in indexed counts.
• The search performance report. New URLs should gain impressions and clicks as they index.
• Server logs and analytics. Check Googlebot activity, unexpected HTTP errors, and visitors moving from old to new URLs.

Expect the first weeks to look untidy. Google's own statement is that medium sites may take a few weeks or more. The signal to act on is not a dip, which is expected, but a pattern: a whole section not being indexed, a spike in not-found errors, or the old addresses still dominating results months later.

How long to keep the redirects

Google says to keep redirects for at least one year, which lets signals and external links transfer, and suggests considering keeping them indefinitely for users, since redirects add some latency. For a small business, there is little cost in keeping the redirect rules in place for good. Make sure that the domain registration for the old domain keeps being renewed. If the old domain lapses and someone else buys it, your redirects vanish and the new owner inherits your old links.

The mistakes Google lists, and how to prevent each

• Leftover noindex or robots.txt blocks. Prevent with a launch-day checklist item that someone other than the developer signs off.
• Redirects to non-existent URLs on the new site. Prevent by testing every row, and by confirming the destination returns a 200.
• Spikes in crawl errors during the migration. Prevent by watching the reports daily for the first fortnight.
• Insufficient server capacity. Prevent by agreeing hosting capacity in advance.
• Outdated or wrong sitemaps. Prevent by generating the sitemap from the live site rather than from a stale export.

Add a few of our own: forgetting that a contact form posts to an old address, leaving the old analytics tag on the new site, and letting an old SSL certificate or domain lapse during the transition. Our guide to the 404 and redirect clean-up covers the day-to-day maintenance of redirects after the move is over.

What to put in the contract

Because a move can damage a site's visibility if it goes wrong, put these items in writing with whoever is doing the work:

• A redirect map delivered for your review before launch, with every old URL accounted for.
• A statement that the move will change one major thing at a time, or an explicit, signed decision to combine them with the risk noted.
• A launch-day checklist covering canonical tags, noindex removal, robots.txt, redirect testing and sitemap submission.
• Search Console access for both properties, owned by you, and the Change of Address submission if a domain changes.
• A monitoring period with named checks, and who is responsible for fixing issues found.
• Confirmation that the old domain stays registered in your name, and that the redirect rules are documented and stay in place for at least a year.
• Your ownership of all accounts, as set out in our website handover and ownership checklist.

If your project is a redesign rather than a pure move, our comparison of redesign versus rebuild will help you decide how much to change and when.

What nobody can promise

No agency can guarantee that rankings will be unchanged, and Google itself says to expect temporary fluctuation. What a careful move can promise is a controlled process: every address accounted for, the right signals in place, and problems caught early. Be sceptical of anyone who promises "zero traffic loss" before they have seen your site.

Working with Govindani Infotech

We are a web development company at 2nd Floor, Landmark Plaza, 206 Satara Road, Parvati Paytha, Pune 411009, and we plan site moves around the redirect map first and the design second. If you are considering a domain change, an HTTPS move or a rebuild and want a review of the risks, our website creation service and SEO service pages describe our work, or you can contact us on 092019 58274. We will look at your current site and tell you what the move involves before any quotation is discussed.

Frequently Asked Questions

Will changing my domain name hurt my Google rankings?

It can cause temporary fluctuation, and Google says medium-sized sites may take a few weeks or more for new URLs to replace old ones. Google also says permanent redirects do not cause PageRank loss, so a well-executed move with one-to-one redirects should not cause a lasting loss. Mistakes in the redirect map are what cause lasting damage.

Should I use a 301 or a 302 redirect when moving a website?

Use a permanent server-side redirect, a 301 or 308, for a move. Google says client-side redirects are a last resort. A temporary redirect signals that the move is not permanent, which is not what you mean.

How long should I keep redirects after moving a site?

Google says at least one year, and suggests considering keeping them indefinitely for users. Keep the old domain registered in your name throughout.

Do I need the Change of Address tool when moving from HTTP to HTTPS?

No. Google says the tool is for domain or subdomain changes only, not for HTTP to HTTPS, www changes or path changes. For HTTPS, redirects and updated canonical tags do the work.

Can I redirect all my old pages to the new home page?

You should not. Google warns that mass-redirecting to the home page can be treated as a soft 404. Redirect each page to its closest equivalent, and let truly retired pages return a 404 or 410.

Sources

• Google Search Central, "Site moves with URL changes": general best practices, preparation steps, URL mapping, redirect strategy, starting the move, the Change of Address tool's scope, keeping redirects at least one year, updating links, monitoring and common mistakes.
• Our own judgement is labelled as such: the crawl-and-merge method for collecting URLs, the contract items, the profile and printed-material checklist and the monitoring cadence are practice, not Google statements.
• The physiotherapy-clinic example is an illustration created for this article, not a client result. We cite no traffic, ranking or recovery figures.

About the author

This guide was written by the web development team at Govindani Infotech, Pune.