There is a problem I’ve wrestled with at pretty much every webapp job I’ve had.
People decide it’s more economical to add more stuff to existing pages than it is to introduce a new page. As time progresses the number of pages goes up logarithmic to the amount of functionality.
This hits on two fronts. One is pressure from the non technical people, who want the cost of new stuff to be O(1). “This is so simple. Why do you have to make it a big deal?” Makes sense the first time. Makes no sense at all the 58th time.
The other one is that we don’t have an easy way to carve up functionality and move it around efficiently. Webpack and friends try to solve this problem, but it leaves a lot to be desired. It’s easier logistically to have the same giant couple of JS bundles where almost every bit of logic is available everywhere. Which makes it more tempting to expose all functionality everywhere.
I discovered at one point that the quite effective strategy I used for maintaining mature wikis is essentially applying the B-Tree algorithm by hand, with depth weighted by recency (eventually all outdated documentation is relegated to the leaves, or updated in order to avoid relegation).
I have a hunch you could do much the same for websites, but I haven’t worked out how to do it in a spirit of refactoring (stability is the first word, but progress has the final say).
There’s a related issue with Conway’s law, where the links on the main page or in the footer are always proportional to the number of divisions in the organization, and the number of initiatives currently in progress or recently finished. This vastly increases the decision tree even when you avoid having a giant landing page. I’ve only seen one solution to this and that is to treat these links as what they are: ads. Ads are either short lived or get rotated frequently to avoid overwhelming the audience.