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 6/8/07, Colin N. [email protected] 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.
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 6/11/07, dave4c03 [email protected] 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.
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.
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
I am simply planning to use a 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.
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
Actually, I’ve got an extension that allows me to add meta keywords and
description to each page. I also added a way to create a unique
for the times I wanted a different one from what’s used in the
tag.
In the layout, I just add a tag like <r:meta_description> and it renders
the whole tag.
I didn’t consider the idea of combining child keywords and I’m not sure
I’d recommend it (a lot of SEO best practices I’ve read seem to think
that you should limit the number of keywords used on a page).
Anyway, I’d be happy to release it but, because it messes with the
edit-page, it really is a job for something like facets (any news on
progress here core team?). Right now, it would break any other
extensions that re-work this page.
The other issue you run into with this approach is that keywords, title,
etc are put on EVERY page which is a bit nonsensical for things like CSS
or javascripts.
What Radiant really needs (IMHO anyway) is some standard method to
handle different page types. That way HTML pages would get all this
stuff and CSS page entry would look different. (Hint, hint core team)
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
Oliver B. 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 11/06/07 11:18 PM, Chris P. 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
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
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
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 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.
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.
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
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
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