Well, there's what's logical for implementation/maintenance, and what's logical for users/usability. The latter falls into the realm of information architecture. Personally, the example currently used by the company seems to be nonsensical and ill-suited for either really.
To start with, I'd use some kind of CMS to handle the implementation/maintenance issue. There are myriad reasons to do this, and enforcing a consistent file structure is just one of the lesser ones. A decent CMS will also let you specify a custom routing system that decouples the information architecture from the file structure used for implementation.
Then you just have to decide on a uniform taxonomy for categorizing the content on the site in the most usable/intuitive fashion. I don't think there's a single standard for this, as it really depends on the content of your site.
You obviously already know to avoid overlapping/redundant categories, so all I can suggest is to give thought to the user experience:
- Who is your target audience? Are there different user segments? If so, perhaps consider segmenting the site based on your main user segments, e.g.
/consumer, /smallbusiness, /enterprise, etc.
- What terminology does your userbase use? What's your user's mental model of your product/service/industry? Looking at search terms both on your internal site search as well as search engine referrals would be useful.
- What are the most common use cases/user scenarios? Create some user stories that represent how/why most of your users would visit your site; then walk through it, putting yourself in their shoes. This may lead you to break the site down by purpose/goal, e.g.
/discover, /browse and /community; or /learn, /shop and /support, etc.
User testing and other UCD techniques could also reveal powerful insights, such as which features/content should be grouped together. To be sure you get things right, continually monitor your site analytics and user feedback, also test, test, and test again.
