What are the best practices for managing large documentation websites with Docusaurus?

[SteveAsterAfovo]

Hi everyone 👋,

I'm currently working on a large-scale documentation platform using Docusaurus, and I'm looking to optimize both the structure and performance as it grows.

I'd love to hear from other users or maintainers:

• How do you organize your content when you have hundreds of docs and multiple teams?
• What strategies or plugins have helped you keep things fast and maintainable?
• Do you use versioning extensively, or prefer other ways to handle doc evolution?
• How do you manage contributor workflows (translations, reviews, CI/CD)?

Any tips, success stories, or even things to avoid would be super helpful to me and others scaling up their use of Docusaurus!

Thanks in advance 🙏
— Steve Aster Afovo

[slorber]

Ultimately, Docusaurus is a SSG, so build time increases when the number of docs increase. I'm constantly trying to improve build times, but we can't eliminate it entirely unfortunately. See also the Docusaurus Faster project on recent releases: #10556

If your site is very large and you have multiple teams, you probably don't want everything to redeploy for all teams and all languages when team 1 fixes a typo in a doc.

Instead of having one big Docusaurus site, you can also create many smaller ones that you interconnect with regular links, that all look the same, and can be deployed/updated independently.

---

For versioning, the strategy I recommend is to "archive" versions that must remain online but that do not receive updates anymore. We use this on our own website. See also: https://reactnative.dev/versions

---

For translations, we use Crowdin as an external SasS to avoid managing translations in Git. There are various strategies that I mentioned in the original design phase: #3317

---

For workflows, you can use something git-based. There are external tools that permit non-technical contributors to contribute, such as Git-based CMS or things like StackBlitz Web Publisher.

[SteveAsterAfovo]

Thanks a lot for your insights!
The idea of splitting the site into smaller, interconnected Docusaurus instances is intriguing. I’ll definitely explore that to reduce build times and isolate team workflows. Archiving older versions instead of maintaining active branches also sounds like a smart approach.

For translations, Crowdin seems like a solid choice, especially for avoiding Git clutter. Did you encounter any challenges integrating it with Docusaurus, or was the setup relatively smooth?

I’ll also check out the Docusaurus Faster project and the React Native versioning example.
If you have any other "lessons learned" from scaling, I’d love to hear them.

Thanks again for sharing your expertise!