ElastiCache website overhaul
Context
Amazon ElastiCache is a managed in-memory caching service that runs multiple open-source engines. For years its documentation was published as two separate sites, one for ElastiCache with Redis and other for ElastiCache with Memcached. Both of these sites were generated from the same base set of XML source files. Splitting them up had initially made sense for marketing reasons.
Problem
By the time I inherited the corpus, several generations of reassigned writers had grown it to thousands of pages across the two sites. The overall content had become difficult to manage due to near-identical pages, key differences that could get lost, and bad SEO that could lead users to the wrong engine for their needs.
From the production end, the build process was extremely involved. Minor changes such as updating links would still require rebuilding the entire site. Those same minor changes could also crash the entire build process, holding back much more important updates such as major feature releases.
Then AWS added a third engine to ElastiCache, Valkey. This was an open-source fork of Redis backed by AWS. Under the existing content model we would either need to either a) build an entirely separate 3rd website, or b) move Valkey onto the Redis site as a sub-variant. Either of these solutions would only increase user confusion, SEO issues, and build difficulties.
Constraints
Launches could not pause for restructuring. Any consolidation had to preserve functionality for existing URLs due to many different external links. It was also vital that the engine differences were clearly documented in an intuitive manner for new and existing users.
Approach
I started before I had a mandate. While continuing to maintain both sites, I opened a separate Git branch and began collapsing them into a single structure. I removed redundant pages, pruned obsolete sections, and mapped where engine-specific content genuinely diverged. I then continued to integrate new features into this separate branch while pushing them to the existing live documentation set. While maintaining these efforts, I presented and pursued the case for consolidation with the ElastiCache PMs.
The Valkey launch became an opportune point to make this change. Rather than confuse customers and search engines further, I proposed that ElastiCache ship one documentation site for this new release. Now all three engines could be covered in one location. Almost all of the end URLs would remain, so existing bookmarks and links could be managed seamlessly with redirects. Those few cases where URLs changed too much for mass redirects could be resolved on an individual basis.
In concrete terms:
- Over 2,000 redundant pages merged or retired
- One united documentation set that matched the live site
- One publish path, one update set of documents, one set of documents for SEO, and only one set of links to maintain
Result
The consolidated site launched alongside Valkey support. Within 3 months, the AWS-specifi Negative Participation Profile (NPP) dropped 9%. Traffic rose approximately 5%. Document production time was easily cut to 1/5th of previous time needs, due mainly to the simplification of internal linking across two different domains.
