Moving a University Repository or Journal Without Breaking Scholar Indexing

A university can move its institutional repository or journal platform to a new address, new software or a new host without losing its Google Scholar indexing, breaking its DOIs or orphaning its Handles. Doing so depends on keeping three layers stable. Every old item URL must permanently (301) redirect to the same item's new landing page. Persistent identifiers (DOIs, Handles and OAI-PMH identifiers) must stay the same while the URLs they resolve to are updated. The new platform must still meet Google Scholar's technical requirements for metadata, crawlable browse pages and robots.txt. Timing matters too. According to Google Scholar's own guidance, updates to papers it has already indexed usually take 6–9 months, and on very large websites can take several years. Redirects from a repository's old addresses therefore need to stay in place for the long term.

This guide is for repository managers, library systems teams, journal managers, university IT departments and research offices. It builds on Webometrics' broader guide to changing a university domain without losing search visibility and backlinks, and focuses on the scholarly infrastructure a general website migration often overlooks.

Why Repository and Journal Moves Need Their Own Plan

A university's main website is mostly discovered through ordinary web search. A repository or journal platform is also discovered through a separate set of scholarly systems, each with its own rules:

• Google Scholar crawls repository and journal sites under its own inclusion guidelines. These require each paper to have its own URL, readable bibliographic meta tags and a crawlable browse interface.
• DOI registration agencies (Crossref for most journal articles, DataCite for many datasets and repository outputs) resolve each DOI to a landing-page URL that the registrant has deposited.
• The Handle System resolves Handle identifiers, which repository software such as DSpace commonly assigns, through the institution's own Handle server.
• Open-access aggregators and registries such as CORE, OpenAIRE and OpenDOAR harvest or list repositories through their OAI-PMH interface, a standard protocol for exposing repository metadata.
• Directories of journals, such as the Directory of Open Access Journals (DOAJ), hold the journal's URL and article metadata.

When a repository or journal moves, each of these systems needs to be dealt with. A move that works perfectly for visitors in a web browser can still leave DOIs resolving through long redirect chains, Google Scholar holding outdated links for months, and aggregators harvesting duplicate or broken records.

Common Migration Scenarios

Several of these often happen at once. Google's site-move documentation recommends making major site changes one after another rather than all together, where possible. For repositories this matters even more, because a problem with metadata output or URL patterns is much harder to trace when the domain, software and hosting have all changed in the same week.

The Identifier Layers: What Must Change and What Must Not

The principle is simple: identifiers persist and locations move. DOIs, Handles and OAI identifiers exist precisely so that citations and harvested records survive a change of location. That only works if the registrant updates where each identifier points.

Step-by-Step: Moving a Repository or Journal Platform

1. Build a Complete URL and Identifier Inventory

Before anything moves, export a complete list of:

• every item, collection and community landing-page URL;
• every full-text file URL, including PDFs referenced in citation_pdf_url meta tags;
• every journal, issue and article URL on a journal platform;
• every DOI the university has registered, with its current resolution URL;
• the Handle prefix in use and how Handles currently resolve;
• the OAI-PMH base URL and the format of OAI identifiers;
• browse and listing URLs, such as lists by date of issue, author or title.

Google's site-move guidance recommends including embedded resources such as images, PDFs and other downloads in the move plan, because they may already receive search traffic and links. For repositories, PDFs often receive more direct traffic and inbound links than landing pages do.

2. Map Every Old URL to Its New Equivalent and Redirect It

Google Scholar's inclusion guidelines state that if articles move to new URLs, the old location of each article should be redirected with an HTTP 301 redirect to its new location. They also state that article URLs should not be redirected to the homepage, because users need to see at least the abstract when they follow a result.

In practice:

• map each old item URL to the same item's new landing page;
• map each old full-text file URL to the new file URL, or to the item's landing page if the file URL cannot be reproduced;
• map old browse, collection and journal-issue URLs to their equivalents;
• for items that have genuinely been withdrawn, return a 404 or 410 status, as Google recommends for deleted content, rather than redirecting to an unrelated page.

When a software upgrade changes how item URLs are built (for example, from a Handle-based path to an internal identifier), the URL map has to be generated from the repository's own database, matching each item's old path to its new one. That mapping is the most valuable artefact of the migration and should be kept permanently.

3. Preserve Google Scholar's Technical Requirements on the New Platform

A new platform or software version can silently change the metadata Google Scholar depends on. Before launch, compare a sample of old and new item pages and confirm that:

• each paper still has its own unique URL;
• the bibliographic meta tags Google Scholar reads are present. Google Scholar supports Highwire Press tags (such as citation_title), bepress tags and PRISM tags, and treats Dublin Core as a last resort. Title, at least one author and the publication date are required;
• citation_pdf_url (or an equivalent tag) points to the new full-text location;
• abstracts are visible without logging in, accepting pop-ups or clicking through. Google Scholar states that sites showing login pages, error pages or bare bibliographic data without abstracts will not be considered for inclusion;
• a browse interface still exists. Google Scholar recommends that every article be reachable from the homepage within at most ten simple HTML links, and that large collections offer listings by publication or record-entry date;
• robots.txt does not block Google's crawlers from articles or browse pages. Staging-environment blocks are a frequent cause of post-launch failure.

Google Scholar recommends DSpace or Digital Commons for university repositories and Open Journal Systems (OJS) for journals. Even with recommended software, configuration and theme customisations should be tested, because they can remove or alter the expected meta tags.

4. Update the Platform's Own URL Configuration

Repository and journal software stores its public address in configuration, and that address is reused in links, sitemaps, OAI-PMH responses and identifier resolution.

• DSpace: the DSpace installation documentation defines dspace.server.url as the complete URL of the backend REST API and dspace.ui.url as the complete URL of the user interface. Both must reflect the new public addresses exactly, and the user interface's own configuration must point to the new REST API address.
• OJS: the base_url setting in OJS's config.inc.php file defines the installation's public address. OJS also supports per-journal base_url overrides for journals served from separate addresses. The configuration also includes the OAI repository_id, which affects the format of OAI identifiers (see step 7).

After changing configuration, regenerate sitemaps and check that links in pages, feeds and OAI-PMH responses use the new address and not the old one.

5. Keep Handles Resolving

Handles such as hdl.handle.net/[prefix]/[suffix] are widely cited in theses, papers and reading lists. In DSpace, a Handle request is passed by the global Handle system to the institution's Handle server, which looks up the item in DSpace and returns its current URL. The DSpace Handle.Net Registry documentation describes this as the main benefit of Handles: the identifier continues to reach the right object even if the repository's main URL changes.

After the move, test a sample of Handles from different years and collections. If the Handle server itself moves to a new host or network address, confirm with the Handle.Net Registry whether the server's registration needs updating. The Handle prefix itself does not change.

6. Update DOI Resolution URLs

A DOI never changes, but the URL it resolves to does. Crossref's metadata-maintenance documentation states that a DOI cannot be changed once registered. It also says that after a platform migration, members can update resource URLs in bulk using a tab-separated file of DOIs and new URLs. DataCite's REST API documentation describes updating a DOI's URL without changing its other metadata.

Relying on redirects alone is not enough. Updating DOI resolution URLs removes an unnecessary redirect from every citation click and protects the DOI if the old domain is ever lost. It also keeps the DOI's registered metadata accurate. Where a journal platform such as OJS deposits DOIs through a plugin, confirm that the plugin's next deposits use the new base_url. Updating the URLs of DOIs that were already registered still has to be handled separately.

7. Keep OAI-PMH Identifiers Stable and Update Harvesters

OAI-PMH is how aggregators collect repository records. Two parts of it behave differently in a move:

• The OAI identifier of each record should stay the same. CORE's Data Provider's Guide recommends that repositories never regenerate OAI identifiers, including during migration to new repository software, and that previously assigned identifiers remain unchanged. When identifiers change, harvesters may treat every record as new, creating duplicates or breaking links to existing records. Where the identifier format includes a hostname or repository ID, keep the existing value in the configuration rather than switching it to the new domain.
• The OAI-PMH base URL will usually change with the hostname, and every service that harvests the repository needs to be told:
• OpenAIRE: repository managers add or update the OAI-PMH interface through the OpenAIRE PROVIDE dashboard. According to OpenAIRE's knowledge base, the aggregation team then evaluates the interface before activating it.
• CORE: the CORE Dashboard allows repository managers to check and revise their OAI-PMH base URL.
• OpenDOAR: Jisc provides an update form for OpenDOAR repository records.
• National and regional aggregators, discovery services and research-information systems that harvest the repository should also be notified.

Keep the old OAI-PMH endpoint redirecting, or answering, for a transition period, so that harvesters that have not yet updated do not record errors.

8. For Journals: Update DOAJ and Indexing Services

The Directory of Open Access Journals' publisher responsibilities state that publishers must keep their journal records up to date. They list a change to the journal's URLs among the changes that require an update request. DOAJ aims to process update requests within one month, and it may withdraw journals whose website is unavailable. The same principle applies to every abstracting and indexing service, library catalogue and national journal register in which the journal is listed.

9. Handle Search Engines as a Site Move

If the repository or journal platform changes hostname, treat it as a site move in Google Search Console as well:

• verify both the old and new hostnames;
• deploy permanent redirects before submitting the move;
• use Search Console's Change of Address tool, which Google states must be used separately for each subdomain variant of the old domain;
• submit new sitemaps listing new URLs;
• monitor indexing and "not found" errors in the old and new properties.

Google Scholar does not use Search Console's Change of Address. It discovers the move by recrawling the old URLs and following their 301 redirects, which is one reason redirects must remain in place for so long.

10. Keep Redirects for the Long Term

Google Scholar states that new papers are normally added several times a week, but updates to papers already included usually take 6–9 months, and updates on very large websites may take several years because the whole site must be recrawled. Google's general site-move guidance recommends keeping redirects for at least one year.

For repositories and journals, the safest policy is to keep redirects from the old addresses in place indefinitely. Repository and journal URLs appear in reference lists, theses, syllabi and other repositories' metadata for decades, and none of those can be updated by the university.

11. Communicate the Change

Tell the people and systems that link to the repository or journal: faculty, research offices, graduate schools, authors, editorial boards, funders, consortium partners and library-discovery providers. Ask researchers to update links in their profile pages and, where they have added repository links directly, in their ORCID records. Publish a short notice on the repository or journal homepage explaining the new address.

Repository and Journal Migration Checklist

Before the Move

• Inventory all item, file, collection, browse and journal URLs.
• Export all registered DOIs and their current resolution URLs.
• Record the Handle prefix, Handle server details, OAI-PMH base URL and OAI identifier format.
• Build and test the old-to-new URL map, including full-text files.
• Compare Google Scholar meta tags on old and new item pages.
• Confirm abstracts are visible without login and browse-by-date listings exist.
• Confirm the new platform's robots.txt and sitemaps.
• Configure the new platform's public URLs (for example dspace.server.url and dspace.ui.url, or OJS base_url).
• Keep the existing OAI identifier format.
• Verify the old and new hostnames in Search Console if the hostname changes.

On Launch Day

• Deploy 301 redirects for items, files, collections, browse pages and journal pages.
• Remove staging restrictions from robots.txt and page-level directives.
• Test redirects for a sample of items from different years, types and collections.
• Test Handle resolution for a sample of Handles.
• Submit new sitemaps and, where the hostname changed, the Change of Address.
• Confirm the OAI-PMH endpoint responds at the new base URL with unchanged identifiers.

First 30 Days

• Submit bulk DOI URL updates to Crossref and update DataCite DOIs.
• Update OAI-PMH base URLs with OpenAIRE, CORE, OpenDOAR and national aggregators.
• Submit DOAJ update requests and notify indexing services for each journal.
• Monitor server logs, Search Console reports and harvester error reports.
• Fix redirect gaps revealed by "not found" errors.

First 6–12 Months and Beyond

• Check that Google Scholar results gradually show the new URLs; Google Scholar indicates this can take 6–9 months, or longer for very large sites.
• Confirm aggregators are harvesting from the new endpoint without duplicate records.
• Spot-check DOI and Handle resolution.
• Keep redirects and the old hostname active indefinitely.
• Archive the URL map and migration documentation.

Common Mistakes

Why This Matters for Webometrics and Research Visibility

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 ranks institutions on three indicators: Impact reflects an institution's presence and recognition across the wider web; Openness and Excellence draw on scholarly data from the UNIRANKS Open Index (OI). These indicators are explained in What Do Impact, Openness and Excellence Mean in the Webometrics Ranking?

A repository or journal migration does not, in itself, change how Webometrics evaluates a university. A migration that breaks redirects, identifiers or harvesting can, however, temporarily reduce how discoverable the institution's open research is across search engines, scholarly indexes and aggregators. A migration that preserves them keeps the institution's research record continuous. Webometrics has previously examined repository discoverability in its study How Visible Are Egypt's University Research Repositories?, which shows how much repository visibility depends on technical implementation.

Frequently Asked Questions

Will moving our repository remove our papers from Google Scholar?

Not if each old item URL redirects with a 301 to the same item's new landing page and the new pages still meet Google Scholar's inclusion guidelines. Google Scholar notes that updates to papers it has already indexed usually take 6–9 months, and can take several years on very large sites, so old URLs may continue to appear during that period.

Do DOIs change when a repository or journal moves?

No. Crossref states that a DOI cannot be changed once registered. What changes is the URL each DOI resolves to, which the registrant must update. Crossref supports bulk URL updates after platform migrations, and DataCite allows a DOI's URL to be updated on its own.

Do Handles still work after a repository changes domain?

They can. Handles resolve through the institution's Handle server, which asks the repository for the item's current location. The repository's URL configuration must be updated, and Handle resolution should be tested after the move.

Should OAI-PMH identifiers change with the new domain?

No. CORE recommends never regenerating OAI identifiers, including during software migrations. Only the OAI-PMH base URL should change, and aggregators such as OpenAIRE, CORE and OpenDOAR need to be told the new base URL.

Is Search Console's Change of Address enough for Google Scholar?

No. Change of Address is a Google Search tool. Google Scholar discovers moved papers by recrawling the old URLs and following 301 redirects, which is why redirects must remain in place.

How long should repository redirects stay in place?

Google's general site-move guidance recommends at least one year, but Google Scholar's longer update cycle and the long life of academic citations make indefinite redirects the safest choice for repositories and journals.

Can full-text PDF links redirect to the item page instead of the new PDF?

Where an exact new file URL exists, redirect to it. Where it does not, redirecting to the item's landing page still gives readers the abstract and a route to the full text, and is consistent with Google Scholar's advice not to send article URLs to a homepage.

Questions about how your institution appears in Webometrics, or about improving its web presence? Contact the Webometrics team.

Sources

• Google Scholar. Inclusion guidelines for webmasters.
• Google Search Central. Site moves with URL changes. Last updated 20 August 2026.
• Google Search Console Help. Change of Address tool.
• DSpace 8.x Documentation (LYRASIS). Installing DSpace.
• DSpace 7.x Documentation (LYRASIS). Handle.Net Registry Support.
• Public Knowledge Project. Open Journal Systems config.inc.php source.
• Crossref. Updating your metadata.
• DataCite Support. Updating metadata with the REST API.
• CORE. Data Provider's Guide.
• OpenAIRE Knowledge Base. How to add a new OAI-PMH interface.
• Jisc. Update an OpenDOAR repository record.
• Directory of Open Access Journals. Publisher responsibilities.
• Webometrics. Methodology.

Suggested Citation

Webometrics (2026). Moving a University Repository or Journal Platform Without Breaking Google Scholar Indexing, DOIs or Handles. Webometrics.org, 10 November 2026. https://www.webometrics.org/insights/support/moving-university-repository-journal-platform-google-scholar-dois