Hi All, Im trying to do SEO with my Radiant site. Can anyone recommend articles / resources relevant to a radiant powered site that I could read to learn how to optimize my site? Thanks, Colin
on 2007-06-09 21:57
on 2007-06-10 10:47
On 6/8/07, Colin Nederkoorn <email@example.com> wrote: > > Can anyone recommend > articles / resources relevant to a radiant powered site that I could > read to learn how to optimize my site? No, they can not. Radiant is just a backend, and what you do with the HTML of your site is totally independent of it. So, there are no SEO articles/resources relevant to Radiant. While coding your layouts and pages, all regular articles still apply: http://del.icio.us/mislav/SEO Here is one tip that you can achieve through Radiant: keep your page titles and slugs descriptive and relevant. Both have much effect on search engine rankings. The rest is up to you.
on 2007-06-11 00:51
I am not certain about this but I think that from a SEO perspective, it would be better if the URL namespace was flat. A flat URL namespace means the navigation structure is not part of the page name. This means a page could participate in or be dropped out of several navigation/menu structures without affecting any local or external pages referencing them. It also means that pages could be dragged/dropped and reordered between directories. For example, given the following radiant file structure root |- A | |- B | | |- C | |- D |- E The pages would be referenced as follows http://localhost:3000/a http://localhost:3000/b http://localhost:3000/c http://localhost:3000/d http://localhost:3000/e However it is important that Radiant still know the parent/child relationships so that navigational menus could still be built. For example, given http://localhost:3000/c the <r:if_ancestor_or_self> tag would identify both A and B as parents which would allow the navigational menus and breadcrumbs to be build properly.
on 2007-06-11 01:00
On 6/11/07, dave4c03 <firstname.lastname@example.org> wrote: > > I am not certain about this but I think that from a SEO perspective, it > would be better if the URL namespace was flat. > > A flat URL namespace means the navigation structure is not part of the > page > name. This means a page could participate in or be dropped out of several > navigation/menu structures without affecting any local or external pages > referencing them. It also means that pages could be dragged/dropped and > reordered between directories. At first I was shocked at what you're suggesting, but now that you've explained it I see you have some valid points. But I'm still not convinced that you should go for flat structure just to please spiders and ease the building of some navigation menus. You should resolve your issues otherwise: for instance, set redirects for spiders from old URLs to the new paths when you move pages around.
on 2007-06-11 05:05
You lose nothing but gain great benefit using a flat URL namespace in a radiant system. It is "having your cake and eating it too!" The benefit accrues because the namespace is not contaminated by the directory structure while at the same time radiant retains and allows the use of and for you to use the directory structure. You design it that way for much the same reasons rails uses id in a SQL database design rather than some form of content based key. It is just fundamentally overall better design being intrinsically more flexible and resilient to change.
on 2007-06-11 07:14
The only SEO feature I could see being nice to implement on the back- end (or extension) side of things would be the ability to easily add a "keywords" string in addition to the slug and title. And then it would be slick for Radiant to automatically dig through all of the parent pages, appending the strings together when you call the tag <r:page:keywords />. Does the page attributes extension allow for something of the sort? I haven't checked that extension out yet. Maybe I'll look into adding such a tag myself if it doesn't yet exist... Matt
on 2007-06-11 10:00
This sounds like a really useful idea, for those who really leverage the hierarchy of the page structure. I'm not I'd want all of the child pages to share keywords with their parents, though. If someone implements this tag, a binary attribute for inheritance would be very useful... though it could get complex beyond one or two levels of depth. Maybe there's a way for an attribute to specify how far back up the tree keywords are aggregated.... Another approach would be to place common groups of keywords in snippets, allowing for many different keyword templates, which could be called from the pages that need them. A third possibility is a single global keyword string for the site, which could be called, or not, on individual pages, in addition to page-level keywords. *dan
on 2007-06-11 12:00
I am simply planning to use a <content part="keywords"> tag to insert the keywords into the meta tag for each page. You probably shouldn't use keyword defaults because each page is individually analyzed. I think you are better off have no keywords than the wrong ones. Obtaining keywords from a parent would simply lower your page rating if those keywords were not supported by that page's content. However, that being said, defaults could be easily set by the use of the inherit="true" parameter on the content tag.
on 2007-06-11 19:38
on 2007-06-12 02:04
dave4c03 wrote: > You lose nothing but gain great benefit using a flat URL namespace in a > radiant system. It is "having your cake and eating it too!" The benefit > accrues because the namespace is not contaminated by the directory structure > while at the same time radiant retains and allows the use of and for you to > use the directory structure. Maybe someone can fill me in or point me to relevant documents. Why is a "flat" URL namespace so much better for search engines than a hierarchical? From an algorithmic point of view I don't seem to see the difference except that a hierarchical space gives you the benefit of a context, which certainly some spiders (should) use. Cheers, Oliver
on 2007-06-12 03:17
I think a flat URL namespace would be slightly better in that it gives you complete flexibility over the URL. For example, you may have a parent page in radiant named 'topic1'. All child pages would then contain 'topic1' in the URL by default. If 'topic1' is not a keyword that the child pages are targeting, then it may "water down" the SEO value of keywords in the child pages' slugs. Even so, I don't think the benefits are great enough to mandate a change in Radiant. I would agree that the current Radiant namespace is a slight disadvantage, but I don't think it's that important. Jay
on 2007-06-12 04:18
Oliver Baltzer wrote: > Maybe someone can fill me in or point me to relevant documents. Why is a > "flat" URL namespace so much better for search engines than a > hierarchical? From an algorithmic point of view I don't seem to see the > difference except that a hierarchical space gives you the benefit of a > context, which certainly some spiders (should) use. Actually, from my research it doesn't seem all that clear that a flat URL tree is better for SEO. It should be obvious to most that some of the best ranking, sites don't put all their pages in the root. That said, I have read several authors who have supposedly tested and seen benefits for smaller sites if all the pages were in the root. What isn't clear, however, is just how old those tests are. Some seem to think that older algorithms simply tracked the depth of the page and made assumptions from that as to how "important" the content must be (I even read one author who seemed to think that page names that were too long would trigger this effect). Anyway, those algorithms also seem to have changed as the search engines have grown up. Most site developers favor the organization that folders bring over the "potential" boost that a flat tree could give. It also seems clear that, if your site has more than one theme, grouping the content into an appropriate folder structure will help the spiders organize your content and can strengthen your rankings for pages. Short Answer - don't bet the farm on any "magic techniques" if they don't make good common development sense. Over time, the engines adapt to eliminate the sneaksters and ensure that those who aren't, aren't penalized. -Chris
on 2007-06-12 05:04
On 11/06/07 11:18 PM, Chris Parrish was heard to say: > Short Answer - don't bet the farm on any "magic techniques" if they > don't make good common development sense. Over time, the engines adapt > to eliminate the sneaksters and ensure that those who aren't, aren't > penalized. That's what I was thinking. I have a 2003 textbook that, among other things, is about crawler technology and even that uses information in the URL to boost the ranking of a page. Additionally, it's a known fact that respected search engine companies recruit only the brightest of the brightest and I am certain somebody there has thought about it. I just found myself confused as there are a few people who seem to be very convinced that a "flat" namespace is the better choice with focus only on SEO. Sure, if somebody is into link spamming and only cares about ranking, rather than providing search capabilities, then that might be the way to go, but if you actually want the search engine to find meaningful results to specific queries, I believe a properly structured content is more beneficial than without any structure. Just my â‚¬0.02. Oliver
on 2007-06-12 05:18
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. 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. Jay
on 2007-06-12 05:54
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 . So they will always focus on finding the user what she/he is looking for and that is content driven. Cheers, Oliver  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.
on 2007-06-12 06:48
jf wrote: > 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. From a practical standpoint... If you look at Radiant's style and purpose, the simplicity of use becomes polluted as we add features like "put this file under this parent... but don't make it act like it has a parent." Sure to confuse basic users. Then there's maintenance. As I look at my tree how do I know which of those leaves are imposters? Do I have to open them one-by-one or do I have some alternate tree (or is it 'lawn') view. Finally, there's namespace issues. For instance, in the following: root |- A | |- B | | |- D | | |- E | | |- F | |- C | | |- D | | |- E | | |- F |- E Which page does http://root/e render? The above is perfectly valid (and common for some sites). Sure you can add validation rules to prevent saving a potential conflictingly-named file (similar to rules that exist for sibling files in a tree) but now you're complicating Radiant's code for a fringe case. So, if what you want is a site with all the pages in the root, why not create all the pages in the root? From a practical standpoint, this is the best. You get what you want, and still make it easy for another person to pick up your project and know exactly what's going on. The UI does its job of showing them what to expect, how it works, and what to do to create more of the same. Oh, *whispers* and be careful throwing around names like Drupal. It's been made very clear that Radiant is not intended to be anything like Druppppaaaacckkrrrgghhh... *death gargle as writer is dispatched by a certain (unnamed) creator of Radiant for even putting that CMS in the same sentence as Radiant* ;) - Chris
on 2007-06-12 09:40
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 2007-06-12 13:38
Ooops -- sorry for mentioning the 'D' word... :-) I completely agree with the desire to keep Radiant as simple as possible, and I'm not lobbying anyone to change the way it works. But, if the issue of SEO comes up, I have to agree that the current namespace is not the best for SEO. Is it worth changing? Probably not. Should we all pretend that the hierarchical naming is better? No, we should recognize that it's slightly disadvantageous, but not a huge issue. > So, if what you want is a site with all the pages in the root, why not > create all the pages in the root? From a practical standpoint, this is > the best Much of Radiant is based upon inheritance of child pages from the parent pages, so sites that use inheritance extensively would not be able to put all the pages in the root. Plus, the folders are great in organizing the content. Once again, it's not a big deal -- just a minor disadvantage. And, as you mentioned, ramping up Radiant's complexity to support every feature would be a disadvantage as well. Jay
on 2007-06-12 16:49
dave4c03 wrote: > - Common sense would suggest that search engines identify context > from that which people "see and use" which is navigational > menus andlinks to the page (and not by deconstructing the URL). You might think that, but it does seem documented that engines deconstruct the URLs and use this info. I think it's fair to say that the linking structure of the site IS more important to them, though. > - 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. That really depends on your organization, doesn't it. A well planned website will usually organize parent/children by their topic creating themes. And you DO want this to show up in your URLs. In fact most testing suggests that this strengthens your site from an SEO perspective. Granted, if you arbitrarily create a structure like example.com/bodies-of-water/tulips/neil-armstrong, the URL probably won't help you. > - Furthermore, as the web site content grows and changes, > as they areprone 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. Sure, but this is wholly separate from everything else. If you move a page, you must either: change all links to it, have some automatic mechanism for changing all links to it, or else have Radiant do a redirect from the old page to the new one for you. Picking a Radiant tree location and a different URL doesn't solve this problem. There has been discussion about this. > - The Menu1/SubMenu2/keyword1-keyword2-keyword3 and the > Menu3/SubMenu4/keyword1-keyword2-keyword3 menu/navi- > gational 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. You can do this today. Make a page with your content at the desired URL. Make another page at another desired URL and include the following in the body: <r:find url="your/first/url"> <r:content /> </r:find> Or, if you want to be TOTALLY abstract, create your pages in any organizational structure you want (say /repository/your/favorite/structure/here) with NO links to that content (maybe even using 'hidden' page type). Then create all the URLs the way you like them and link to your content in the repository. This solution affords you the benefit of a tree view that shows you the different URL structures that you are using while allowing you to store your content in some other structure. Personally, I'd work on organizing my site based on SEO themes and gain the benefits of simplicity and not having to worry about Google changing their algorithms to penalize people with 10 "different" pages that all have the same content (because this matches spammer behavior). -Chris
on 2007-06-12 16:57
jf wrote: > Once again, it's not a big deal -- just a minor disadvantage. It seems like the engines LIKE to see your themes, linking structure, and urls all reinforce each other. So, a site that is structurally organized (this means subfolders) the same way as its linking and themes are, is an advantage. Of course if you only have a single SEO theme to your site then you would rightly put all the content in the root (in this case, you wouldn't have too much content either so it works out nicely). -Chris
on 2007-06-12 17:17
I agree with everything Chris said just now. Stop worrying and simply use Radiant. Use hierarchies, nested menus, deep URLs and good, usable navigation patterns. Make your visitors happy. While doing that, simply code towards good SEO practices on the way. Spiders won't mind how you organized your site. Use "description" page parts for your pages and render the meta tag in the layout. Use nice titles and readable slugs. After you're done, you can also create a sitemap for your site. There is vanilla Radiant way and there is a plugin, if I'm not mistaken. Search the archives.