How Hindawi migrated 4 million pages to a new platform and grew organic clicks by 66%

Hindawi is one of the world’s largest open-access academic publishers. The brief for the replatform sounded simple enough: rebuild the site from scratch, without breaking what Google had spent years learning about it. That second part was the real work.

Replatforming a site Google already understood

The old CMS had been built before mobile existed. A responsive template had been retrofitted over the years, but it never worked well enough to be a real mobile experience. Load times were poor, and the platform had accumulated structural SEO issues that could not be patched properly without a rebuild.

The bigger risk was indexation. Every paper had a printer version, a separate abstract page, and a separate references page. At Hindawi’s scale, those variants had multiplied the site’s footprint several times over. The sitemap listed around a million URLs, but crawl analysis showed the real footprint was closer to 4 million.

Getting a full picture of the site was not straightforward. The crawl had to be segmented and processed outside normal desktop tools before it could be used for analysis. That mattered because the migration plan could only be safe if the old site was properly understood first.

There was also a dependency most commercial sites do not have. Academic papers get found and cited through Google Scholar, which reads structured citation metadata in the page head to identify, attribute, and index research correctly. A break in that metadata meant papers became harder to find and cite. A traffic problem, yes, but a credibility one too.

The backlink profile added another layer of risk: 8.2 million links from 39,000 domains, built up over years around peer-reviewed content that ranked well because it deserved to. All of it had to survive the migration intact.

Reducing the risk before the new site launched

The first call was on URLs. Change the journal and article URL structure significantly and Google has to re-evaluate the content from scratch. On a site of this size, that process takes months and traffic drops while it happens.

The decision was to keep the URL format as close to identical as possible. Journal abbreviations were expanded into full names, but the article IDs, folder structure, and path logic stayed intact. Google’s existing understanding of the content could transfer to the new site without starting over.

Before the new site launched, the index bloat on the old site had to be addressed. Every paper had a printer version, a separate abstract page, and a references page, each indexable at scale. Getting those out of Google’s index ahead of go-live meant crawl budget on the new site would go to content that mattered, not thousands of near-duplicate variants of the same papers. That work reduced the site’s indexed footprint from approximately 4 million pages to around 1 million. When the new platform launched, Google arrived with a much cleaner read of which pages were worth crawling. Faster crawl coverage and indexation on the new site was a direct result of what had been done on the old one.

The cleanup on the old site was as important as anything done on the new one. It is the step most migrations skip.

With the URL strategy and index cleanup in place, the next layer was the technical specification for the new Drupal build. It covered the parts of the platform that could quietly break organic visibility: citation metadata for Google Scholar, canonicals, pagination, JavaScript rendering, XML sitemaps, robots directives, and mobile layout requirements. Each of those elements can fail without an obvious error, and at this scale the cost of finding out after launch is significant.

During pre-production testing, Google indexed thousands of pages from the test environment. The easy fix would have been to block the site in robots.txt, but that would have stopped Google seeing the noindex signal and kept the URLs indexed for longer. The correct response was noindex plus password protection, so the unwanted pages could be removed properly.

Late in the build, a review found that some structural recommendations still needed work. The deadline was not moving, so the right call was triage: fix what could damage launch, defer lower-risk items, and keep the migration moving without pretending everything had equal weight.

No traffic loss. Faster crawling. Record organic performance.

When the new site went live, traffic did not dip. Gains were visible from day one.

Organic clicks in the month of launch were 5.17 million, against 3.12 million in the same month the previous year. A 66% year-on-year increase. Organic impressions grew from 102 million to 238 million over the same period, a 133% increase. Google Scholar indexation was seamless. Article pages carried their citation metadata forward intact, and papers remained findable and citable without interruption.

5.33 million organic users in the month that followed. An all-time record, set six weeks after launch.

The numbers came from decisions made months before launch. Clearing the index bloat ahead of go-live meant Google came to the new platform with a cleaner picture of which content mattered. URL continuity meant accumulated trust transferred without Google re-evaluating the site from scratch. The specification work meant the new platform gave search engines more to work with, not less, than the old one.

This is where migration SEO has to sit inside the build, not after it. The important decisions were made while the new platform was still being shaped.