In reading the comments in general I see some people have, and some people have not, collapsed some concepts that are far more powerful when separated. For example:
- The URL is simply a globally uniquely addressable resource from a REST perspective (eg. http://example.com/keyword1-keyword2-keyword3). - The URL is simply the site's landing page for a specific set of keywords (eg, keyword1-keyword2-keyword3) from an SEO perspective. - Common sense would suggest that search engines identify context from that which people "see and use" which is navigational menus and links to the page (and not by deconstructing the URL). Given the above conceptual model and with clarity of thought and purpose, you should choose a URL name with keywords totally under YOUR control. There should be no attempt to game the system only to crisply and clearly communicate with it. - You do not want to contaminate the URL in any way and that means you do not want keywords that are not supported by the page content in your URL. In particular, you do not automatically want any navigational context keywords or directory structure keywords in your URL. - Furthermore, as the web site content grows and changes, as they are prone to do, you want to be able to move the page and change the menu/navigational structures without breaking internal or external links to a URL resource. (Also, you might want to convert an existing site to radiant without breaking links which would allow that site to grow and change.) - The Menu1/SubMenu2/keyword1-keyword2-keyword3 and the Menu3/SubMenu4/keyword1-keyword2-keyword3 menu/navigational structures should both refer to the same page ( http://example.com/keyword1-keyword2-keyword3). After all, a page should be able to participate in multiple navigational contexts. In short, URLs should be totally independent of menu or directory structure for many reasons, SEO among them. On 6/11/07, Oliver Baltzer <[EMAIL PROTECTED]> wrote: > > On 12/06/07 12:16 AM, jf was heard to say: > > I think the original person's point was that a flat namespace allows > > you to design the URL structure that fits your scenario best. So, if > > you want a page to appear to be part of a folder, then you can assign > > it an appropriate slug. If you want child pages to not carry the name > > of a folder in the URL, then you have that option as well. Drupal is > > a good example of a CMS that allows this flexibility. > > The question I have here is: Why would you want to put the child in > that folder in the first place? > > > Carefully choosing a URL does not mean that someone is "link > > spamming", or "only cares about ranking". Let's face it, if you're > > going to go through the trouble of spending 100's of hours building > > your killer app, or fabulous website, you might as well do all you can > > to help people find it. > > Exactly and finding a site is about achieving a high ranking despite > the content. There is a difference between allowing a user to find the > information they are looking for and bringing the user to your website > based on the information they are looking for. Current search engines > are not the Yellow Pages and I don't think they want to be [1]. So > they will always focus on finding the user what she/he is looking for > and that is content driven. > > Cheers, > Oliver > > [1] Certainly there are exceptions to the rule and for example Google > does a fairly good job in distinguishing between those two types > of queries and produces reasonable results for each of them. > > > > _______________________________________________ > Radiant mailing list > Post: [email protected] > Search: http://radiantcms.org/mailing-list/search/ > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > > _______________________________________________ Radiant mailing list Post: [email protected] Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
