University Domain Change: Protect Search Visibility and Backlinks

A university can change its official domain, for example from olduniversity.edu to newuniversity.edu, without permanently losing its search visibility, backlinks or web impact. Whether it does depends almost entirely on how the move is carried out. The three mechanisms that matter most for Google Search are one-to-one permanent (301 or 308) redirects from every old URL to its equivalent new URL, verification of both the old and new domains in Google Search Console, and Google's Change of Address tool. Rebranding the homepage, updating Google Analytics or editing social-media profiles does not tell Google Search that a site has moved.

This guide explains what Google's current documentation says about site moves, what happens to backlinks and indexed pages, and which academic and institutional systems a university also needs to update. It is written for university IT departments, web administrators, communications teams and SEO staff. Most of the principles apply equally to research institutes, colleges and other organisations.

What Is a Domain Migration?

A domain migration is the permanent move of a website from one domain name to another, with each old URL redirected to its corresponding new URL so that users, search engines and linking websites reach the same content at its new address. Google calls this a site move with URL changes. It is a different exercise from redesigning a website, replacing a content management system or moving to a new hosting provider, although these changes are often made at the same time.

Universities change domains for many reasons: an institutional name change, a merger of two or more institutions, a move from a generic domain to a national academic domain (or the reverse), the consolidation of several legacy domains, or a rebrand. Whatever the reason, the old domain usually carries decades of accumulated signals: links from other universities, government agencies, publishers and news media; indexed pages in search engines; citations in theses, papers and policy documents; and researcher profiles across scholarly platforms.

Webometrics' own best-practice guidance for universities recommends using a single, consistent institutional domain and avoiding domain changes or multiple main domains. When a change is unavoidable, the goal is to make it complete, permanent and well documented.

How Google Handles a Domain Change

Google's site-move documentation (last updated 20 August 2026) describes a domain move as a process of preparing the new site, mapping old URLs to new URLs, deploying redirects and then monitoring the transition. Four points from Google's guidance shape everything else:

• Permanent redirects are the core signal. Google's redirects documentation states that for permanent server-side redirects (301 and 308), Google's indexing pipeline uses the redirect as a signal that the redirect target should be canonical. Temporary redirects (302, 303 and 307) are not treated as that signal, and Google may keep showing the old URL.
• Change of Address supports the move. Google's Change of Address documentation explains that the tool tells Google to prioritise crawling and indexing the new site over the old one, and forwards signals from the old site to the new one for 180 days. It works only for domain-level moves and requires 301 redirects to be in place first.
• Some fluctuation is normal. Google states that rankings may fluctuate while it recrawls and reindexes a moved site, and that for a medium-sized site it can take a few weeks or more before Google gradually shows the new URLs instead of the old ones. Larger sites can take longer. University websites, which often contain hundreds of thousands of URLs across many subdomains, fall into the second group.
• Moves should be sequenced. Google advises planning site changes one after another rather than all at the same time, for example moving to a new domain, changing the CMS and redesigning the layout as separate steps.

Google Analytics Does Not Notify Google Search

A common misunderstanding is that updating Google Analytics, or Google Analytics 4 (GA4), informs Google that a website has moved. It does not. Google Analytics measures visitor behaviour on pages where its tag is installed; it is not a channel for communicating site moves to Google Search. The mechanisms Google Search relies on are permanent redirects, Search Console verification of both domains and the Change of Address tool, supported by updated canonical tags, internal links and sitemaps. Analytics configuration matters for continuity of reporting, which is covered below, but it has no role in how Google indexes the new domain.

What Happens to Backlinks When You Change Domains?

Backlinks pointing to the old domain continue to have value after a domain change if each old URL permanently redirects to its corresponding new URL. Google's site-move guidance is explicit that 301 and other permanent redirects do not cause a loss in PageRank, the link-based signal Google has long used. It also recommends keeping redirects for at least one year so that Google can transfer signals to the new URLs, including recrawling and reassigning links on other websites that still point to the old addresses.

Three conditions determine whether that transfer works well:

1. Redirects must be one-to-one wherever possible. A link to olduniversity.edu/faculty-of-engineering/admissions should lead to newuniversity.edu/faculty-of-engineering/admissions, not to the new homepage. Google warns against redirecting many old URLs to a single irrelevant destination such as the homepage, because it confuses users and may be treated as a soft 404, a page Google considers equivalent to "not found". Google Scholar's inclusion guidelines make the same point for academic content: article URLs should be redirected to their new locations with 301 redirects, and should not be redirected to the homepage.
2. Redirects must stay in place. When a redirect is removed, external links to the old URL lead nowhere, and the signal they carried has no destination.
3. Redirects should be direct. Google notes that Googlebot can follow up to 10 redirect hops, but recommends keeping chains short, ideally no more than three. A migration that adds a new redirect on top of older legacy redirects (http → https → www → new domain → new path) should be flattened so that each old URL points straight to its final destination.

For content that genuinely no longer exists, Google recommends returning a 404 or 410 status code rather than forcing a redirect to an unrelated page. For content that was merged, the closest equivalent page is usually the right target.

Redirects preserve backlinks; they do not replace them. Over time, updating the most important external links at their source (partner universities, ministries, accreditation bodies, publishers and major directories) removes a dependency on the old domain and gives users a faster, direct path.

The Technical Migration: Twelve Steps Based on Google's Guidance

1. Build a Complete URL Map

The URL map is the foundation of the whole migration. Google recommends compiling old URLs from existing sitemaps, server logs, analytics data, Search Console's Links report and the CMS itself, including embedded resources such as images, PDFs, videos, CSS and JavaScript files. Each old URL is then mapped to its new equivalent.

At a university, this inventory must extend well beyond the main website. It should include faculty and department sites, the library, the institutional repository, open journal platforms, research centre sites, the news archive, staff profile pages, admissions portals, course catalogues and any document libraries that hold policies, theses or reports.

2. Use Permanent, Server-Side Redirects (301 or 308)

Google recommends HTTP permanent redirects, such as 301 and 308, and identifies server-side redirects as the most reliable method. Under the HTTP standard (RFC 9110), both 301 (Moved Permanently) and 308 (Permanent Redirect) indicate that a resource has a new permanent address; the difference is that 308 does not allow a client to change the request method (for example from POST to GET), while 301 does. For ordinary web pages either is appropriate. JavaScript redirects should be a last resort, because Google may not always render them.

Test redirects before and after launch, using Search Console's URL Inspection tool and command-line or crawler-based checks of the full URL map.

3. Cover Every Host Variant and Subdomain

A domain migration includes every variant through which the old site can be reached: olduniversity.edu, www.olduniversity.edu, the http and https versions, and every subdomain such as library.olduniversity.edu, repository.olduniversity.edu or journals.olduniversity.edu. Each should redirect to its correct equivalent on the new domain. Subdomains are where university migrations most often fail, because they are frequently run by different teams or external vendors.

Webometrics has previously examined how policies can differ across a single institution's separate web properties, in its study of AI-crawler directive consistency across university web properties. The same fragmentation affects migrations: a subdomain no one remembered can stay on the old domain for years.

4. Verify Both Old and New Properties in Search Console

Google recommends verifying both the old and the new site in Search Console, including their variants. Search Console offers two property types: a Domain property, verified through a DNS record, covers all subdomains and protocols, while a URL-prefix property covers only URLs under one specific prefix and can be verified in several ways. For a university migration, Domain properties for both the old and the new domain give the broadest monitoring view.

If verification uses an HTML file, that file must also exist on the new site. Google also advises reviewing settings carried by the old property, for example re-uploading any disavow file to the new property.

5. Submit the Change of Address

Once redirects are live, the owner of both properties, using the same Google account, submits the move through Search Console's Change of Address tool. The tool runs validation checks, including whether the old homepage redirects to the new one. According to Google:

• the tool applies to domain-level moves (example.com to example.org, or one subdomain to another), not to moves within a path or to http-to-https changes;
• it does not move subdomains automatically; it must be used for each subdomain variant of the old domain, including www and non-www, even if some are rarely used;
• it does not remove old URLs from Google's index on its own.

6. Update Canonical Tags, hreflang and Internal Links

Every page on the new domain should carry a self-referencing rel="canonical" tag pointing to its new URL. Google's canonicalization documentation describes redirects and canonical tags as strong signals and sitemap inclusion as a weaker one, and warns against sending conflicting signals for the same page. A new page that still declares an old-domain URL as canonical works against the redirect.

Multilingual university sites should update all hreflang annotations to the new URLs. All internal links, including navigation menus, footers, breadcrumbs, embedded links in news articles and links inside PDFs that the university controls, should point directly to the new domain instead of relying on redirects.

7. Update XML Sitemaps and robots.txt

Google recommends submitting a sitemap of the new URLs once redirects are live. Sitemaps should list only final, canonical new-domain URLs. Before launch, check the new site's robots.txt and page-level directives: staging sites are commonly protected with Disallow: / or noindex, and these settings must not be carried into production. The old domain should also remain crawlable, because search engines can only discover a redirect on a URL they are permitted to request.

8. Keep the Redirects and the Old Domain

Google's guidance differs slightly by document, but always points in the same direction:

For universities, Webometrics recommends treating the old domain as a permanent institutional asset rather than a temporary one. Academic references have unusually long lives: theses, journal articles, books, accreditation reports, government documents and printed material can cite a university URL for decades. Keeping the old domain registered and redirecting indefinitely protects those references. An expired university domain can also be registered by a third party, who would then receive the institution's historical links and traffic.

9. Monitor Indexing and Crawl Errors

After the move, Google suggests watching the sitemaps and indexing reports for both properties, checking for unexpected increases in "not found" errors, and tracking whether the new URLs are gaining impressions and clicks in the Performance report. Server logs should be monitored too: Google notes that it temporarily crawls more heavily after a site move, so the new servers need enough capacity.

10. Update External Backlinks Where Practical

Google recommends contacting the websites that link to the old URLs, prioritising the most important ones, and updating social-media profiles and advertising landing pages. Search Console's Links report for the old property is a practical starting list. For universities, the most valuable links usually come from partner institutions, government and accreditation bodies, research funders, publishers, library catalogues and news media.

11. Configure Google Analytics 4 for Continuity

GA4 matters for measurement, not for search engines. The Google Analytics help documentation confirms that a web data stream's name and website URL can be edited from the stream details screen, so the stream can be updated to reflect the new domain. Because GA4 collects data through the Google tag installed on each page, keeping the same tag on the new domain keeps reporting within the same property. Google's site-move documentation also notes that some teams may prefer a new analytics profile if they want clean separation in their reports, so the choice depends on reporting needs.

If old and new domains both serve live content during a transition, or if visitors move between separate institutional domains, GA4's cross-domain measurement can keep sessions joined across domains. Record the migration date in internal reporting, so that changes in traffic, referral sources and landing pages can be interpreted correctly afterwards.

12. Do Not Forget Other Search Engines

Google is not the only discovery channel. Microsoft Bing Webmaster Tools includes a Site Move tool that also requires site verification and 301 redirects. Other crawlers, including those used by AI search tools, generally rely on the same redirects, links and sitemaps to find content at its new address.

Beyond Search Engines: The University's Academic and Institutional Ecosystem

A university's domain appears in hundreds of places outside its own website. Updating these is not a signal to Google Search that the site has moved; that remains the job of redirects and Search Console. These updates matter because they keep the institution's identity consistent, keep research discoverable and reduce dependence on redirects over time.

University Domain Migration Checklist

Before the Migration

• Confirm the reason for the change and secure approval from leadership, IT, communications, library and research offices.
• Appoint one owner for the migration and one owner for each subdomain or external platform.
• Register the new domain and confirm the renewal arrangements for both domains.
• Inventory every hostname, subdomain and vendor-hosted service on the old domain.
• Build a complete one-to-one URL map, including PDFs, images, repository items and legacy URLs that are already redirected.
• Verify Domain properties for both old and new domains in Search Console, and both sites in Bing Webmaster Tools.
• Export baseline data: top landing pages, top linked pages, indexed page counts, Search Console performance data and analytics benchmarks.
• Prepare new XML sitemaps containing only new-domain URLs.
• Prepare canonical tags, hreflang annotations and internal links on the new domain.
• Plan to change the domain separately from a CMS change, redesign or URL restructure where possible.
• Choose a lower-traffic period, avoiding admissions deadlines, results announcements and enrolment.
• Confirm server capacity for increased crawling and notify the hosting provider.
• Prepare lists of external links to update and of academic records (DOIs, repository registrations, ROR, directories) that need changing.

On Migration Day

• Remove staging-only noindex tags and robots.txt blocks from the new site.
• Deploy 301 or 308 redirects across all host variants and subdomains.
• Test a representative sample of redirects, including deep pages, PDFs and repository items; check that none leads to the homepage by default and that no chains remain.
• Check that the new homepage returns 200 OK and that its canonical tag points to itself.
• Submit Change of Address in Search Console for the old domain and each of its subdomain variants.
• Use Bing Webmaster Tools' Site Move feature.
• Submit the new XML sitemaps.
• Update the GA4 web data stream and confirm data collection in the Realtime report.
• Publish an announcement of the new domain on the university website and official channels.

First 30 Days

• Monitor indexing, sitemap and "not found" reports for both Search Console properties daily at first, then weekly.
• Review server logs for redirect errors, 404s and crawl volume.
• Fix incorrect or missing redirects identified by crawl errors.
• Update social-media profiles, Google Business Profile listings and official email signatures.
• Begin updating the highest-value external links: government, accreditation, partner universities, funders and major directories.
• Update DOI resolution URLs with Crossref and DataCite, and repository registrations with aggregators.
• Ask researchers to update Google Scholar homepage links, verified email addresses and ORCID website links.
• Submit a ROR curation request and update Wikidata and Wikipedia records in line with their editorial policies.

First 3–6 Months

• Compare indexed pages, impressions and organic traffic against the pre-migration baseline.
• Confirm that old URLs are gradually being replaced by new URLs in search results.
• Continue outreach on external links, working down from the most important.
• Audit remaining internal links, PDFs and templates for references to the old domain.
• Check that no subdomain or vendor-hosted service has been left on the old domain.
• Keep the old domain registered and all redirects active; do not cancel the Change of Address.
• Document the migration, including the URL map, dates and decisions, for future teams.

Common Domain Migration Mistakes

Why Domain Migrations Matter for Webometrics and Institutional Web-Impact Analysis

Webometrics is a UNIRANKS project dedicated to the development and application of webometric university evaluation and research; Webometrics.org is the project's dedicated public website and publication platform. The current Webometrics methodology evaluates universities through three indicators: Impact, Openness and Excellence. These are explained in more detail in What Do Impact, Openness and Excellence Mean in the Webometrics Ranking?

Two parts of the methodology are directly relevant to a domain change.

First, attribution depends on the institutional domain. The methodology states that each institution is associated with a verified primary institutional domain, that eligible digital resources must be sufficiently attributable before they contribute to institutional measurement, and that one normalised domain represents one web asset. When a university moves to a new primary domain, the association between the institution and its new domain needs to be clear and consistent.

Second, Webometrics does not rank universities by their position in Google. The methodology describes a multi-source data architecture in which different measurement categories may rely on different validated sources, and no single external provider independently determines an institution's ranking. Search-engine visibility is one of the areas the Impact indicator considers, alongside web authority, digital reach and online presence, with web signals analysed through UNIRANKS Web Growth Intelligence (GI) and research intelligence through the UNIRANKS Open Index (OI).

A domain migration does not, on its own, change how Webometrics measures a university. A poorly executed migration can, however, temporarily fragment or disrupt the web signals that any web-impact analysis observes: links may point to an old domain that no longer resolves, content may be split across two domains, subdomains may be left behind, and search engines may take longer to recognise the new site. A carefully executed migration, with one-to-one permanent redirects, consistent identity records and an old domain that remains active, keeps that historical web presence connected to the institution.

Universities that change their primary domain should make sure the new domain is consistently declared across their own website, scholarly registries and public directories, and can inform Webometrics of the change through the Webometrics contact page. For broader context on the signals that make a university website authoritative, see What Makes a University Website Authoritative? Digital Presence Signals That Matter and What Is a Web Ranking?

Key Takeaways

• A domain change is communicated to Google Search through permanent redirects, Search Console verification of both domains and the Change of Address tool, not through Google Analytics.
• Backlinks keep their value when each old URL permanently redirects to its equivalent new URL; Google states that permanent redirects do not cause a loss in PageRank.
• Redirects should be one-to-one, direct and permanent; redirecting everything to the homepage undermines the move.
• Google recommends keeping redirects for at least one year; for universities, keeping the old domain and its redirects indefinitely is the safest way to protect long-lived academic references.
• Universities must also update DOIs, repositories, scholarly profiles, registries, directories and partner links, because a university's domain is embedded in a much wider academic ecosystem than a typical organisation's.

Frequently Asked Questions

Will my university lose its Google rankings if it changes domain?

Some temporary fluctuation is normal. Google states that rankings may fluctuate while it recrawls and reindexes a moved site, and that a medium-sized site may take a few weeks or more before the new URLs replace the old ones in results, with larger sites taking longer. A well-executed migration aims to make this disruption temporary; no migration method can guarantee unchanged rankings.

Should a university use 301 or 308 redirects?

Google treats both 301 and 308 as permanent redirects and recommends either. The difference under the HTTP standard is that 308 preserves the request method, which matters for forms or APIs that receive POST requests. For ordinary web pages, 301 is the most widely used.

How long should a university keep redirects from the old domain?

Google's site-move documentation recommends keeping redirects as long as possible, generally at least one year, and its Change of Address documentation recommends at least 180 days and longer while traffic continues. Because academic references can persist for decades, universities should plan to keep the old domain registered and redirecting indefinitely.

Does updating Google Analytics tell Google about a domain change?

No. Google Analytics measures visitors to pages where its tag is installed. It does not notify Google Search of a site move. Use permanent redirects, verify both domains in Search Console and submit a Change of Address.

Does updating Google Scholar profiles tell Google Search that the website moved?

No. Updating Google Scholar profiles keeps researcher homepages and verified institutional email addresses accurate and supports academic discoverability, but it is not a site-move signal for Google Search.

Is the Change of Address tool needed when moving from http to https or from www to non-www?

No. Google states that the Change of Address tool is not needed for http-to-https moves or for www/non-www changes on the same domain. It is used when moving to a different domain or subdomain.

What happens to subdomains such as library or repository sites?

They need to be migrated and redirected individually. Google's Change of Address tool does not move subdomains automatically, so each old subdomain that moves to a new domain needs its own redirects and its own Change of Address submission.

Can a university move only part of its website to a new domain first?

Yes. Google suggests that large sites may move a section first to test the effect on traffic and indexing, while noting that a partial move is not necessarily representative of a whole-site move.

Does a domain change affect a university's Webometrics results?

The Webometrics methodology associates each institution with a verified primary institutional domain and uses a multi-source data architecture rather than search rankings from any single provider. A well-managed migration keeps an institution's web presence connected; a poorly managed one can temporarily fragment the signals that web-impact analysis observes. Universities should keep their new domain consistent across all official records.

Sources

• Google Search Central. Site moves with URL changes. Last updated 20 August 2026.
• Google Search Console Help. Change of Address tool.
• Google Search Central. Redirects and Google Search. Last updated 14 April 2026.
• Google Search Central. How to specify a canonical URL with rel="canonical" and other methods. Last updated 10 July 2026.
• Google Search Console Help. Add a website property to Search Console.
• Google Analytics Help. Edit or delete accounts, properties and data streams.
• Google Analytics Help. Set up cross-domain measurement.
• Google Scholar. Inclusion guidelines for webmasters.
• Google Scholar. Google Scholar Citations profiles.
• Microsoft Bing Webmaster Blog. Website Migration with Bing. 17 December 2020.
• IETF. RFC 9110: HTTP Semantics, sections 15.4.2 and 15.4.9.
• Crossref. Updating your metadata.
• DataCite Support. Updating metadata with the REST API.
• Research Organization Registry. ROR updates and curation.
• Wikipedia. Wikipedia:Conflict of interest.
• Webometrics. Methodology.
• Webometrics. Best Practices.

Suggested Citation

Webometrics (2026). Changing Your University Domain Without Losing Google Visibility, Backlinks and Web Impact. Webometrics.org, 2 October 2026. https://www.webometrics.org/blog/university-digital-strategy/changing-university-domain-search-visibility-backlinks