# SEO in Radiant

**URL:** <https://www.ruby-forum.com/t/seo-in-radiant/106399>\
**Category:** Radiant CMS\
**Created:** [June 9, 2007, 9:57pm UTC](https://www.ruby-forum.com/t/seo-in-radiant/106399 "2007-06-09T21:57:44Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![nolic](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/13edae/32.png) [@nolic](https://www.ruby-forum.com/u/nolic)\
**Post date:** [June 9, 2007, 9:57pm UTC](https://www.ruby-forum.com/t/seo-in-radiant/106399/1 "2007-06-09T21:57:44Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![nolic](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/13edae/32.png) [@nolic](https://www.ruby-forum.com/u/nolic)\
**Post date:** [June 10, 2007, 10:47am UTC](https://www.ruby-forum.com/t/seo-in-radiant/106399/2 "2007-06-10T10:47:50Z")

</div>

On 6/8/07, Colin N. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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](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.

---

<div class="post-metadata">

**Author:** ![nolic](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/13edae/32.png) [@nolic](https://www.ruby-forum.com/u/nolic)\
**Post date:** [June 11, 2007, 12:51am UTC](https://www.ruby-forum.com/t/seo-in-radiant/106399/3 "2007-06-11T00:51:26Z")

</div>

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/a)  
[http://localhost:3000/b](http://localhost:3000/b)  
[http://localhost:3000/c](http://localhost:3000/c)  
[http://localhost:3000/d](http://localhost:3000/d)  
[http://localhost:3000/e](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](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.

---

<div class="post-metadata">

**Author:** ![nolic](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/13edae/32.png) [@nolic](https://www.ruby-forum.com/u/nolic)\
**Post date:** [June 11, 2007, 1:00am UTC](https://www.ruby-forum.com/t/seo-in-radiant/106399/4 "2007-06-11T01:00:26Z")

</div>

On 6/11/07, dave4c03 [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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.

---

<div class="post-metadata">

**Author:** ![nolic](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/13edae/32.png) [@nolic](https://www.ruby-forum.com/u/nolic)\
**Post date:** [June 11, 2007, 5:05am UTC](https://www.ruby-forum.com/t/seo-in-radiant/106399/5 "2007-06-11T05:05:44Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![nolic](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/13edae/32.png) [@nolic](https://www.ruby-forum.com/u/nolic)\
**Post date:** [June 11, 2007, 7:14am UTC](https://www.ruby-forum.com/t/seo-in-radiant/106399/6 "2007-06-11T07:14:52Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![nolic](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/13edae/32.png) [@nolic](https://www.ruby-forum.com/u/nolic)\
**Post date:** [June 11, 2007, 12:00pm UTC](https://www.ruby-forum.com/t/seo-in-radiant/106399/7 "2007-06-11T12:00:27Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![nolic](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/13edae/32.png) [@nolic](https://www.ruby-forum.com/u/nolic)\
**Post date:** [June 11, 2007, 10:00am UTC](https://www.ruby-forum.com/t/seo-in-radiant/106399/8 "2007-06-11T10:00:13Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![nolic](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/13edae/32.png) [@nolic](https://www.ruby-forum.com/u/nolic)\
**Post date:** [June 11, 2007, 7:38pm UTC](https://www.ruby-forum.com/t/seo-in-radiant/106399/9 "2007-06-11T19:38:38Z")

</div>

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)

---

<div class="post-metadata">

**Author:** ![nolic](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/13edae/32.png) [@nolic](https://www.ruby-forum.com/u/nolic)\
**Post date:** [June 12, 2007, 3:17am UTC](https://www.ruby-forum.com/t/seo-in-radiant/106399/10 "2007-06-12T03:17:09Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![nolic](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/13edae/32.png) [@nolic](https://www.ruby-forum.com/u/nolic)\
**Post date:** [June 12, 2007, 4:18am UTC](https://www.ruby-forum.com/t/seo-in-radiant/106399/11 "2007-06-12T04:18:06Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![nolic](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/13edae/32.png) [@nolic](https://www.ruby-forum.com/u/nolic)\
**Post date:** [June 12, 2007, 5:04am UTC](https://www.ruby-forum.com/t/seo-in-radiant/106399/12 "2007-06-12T05:04:25Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![nolic](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/13edae/32.png) [@nolic](https://www.ruby-forum.com/u/nolic)\
**Post date:** [June 12, 2007, 2:04am UTC](https://www.ruby-forum.com/t/seo-in-radiant/106399/13 "2007-06-12T02:04:04Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![nolic](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/13edae/32.png) [@nolic](https://www.ruby-forum.com/u/nolic)\
**Post date:** [June 12, 2007, 5:18am UTC](https://www.ruby-forum.com/t/seo-in-radiant/106399/14 "2007-06-12T05:18:26Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![nolic](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/13edae/32.png) [@nolic](https://www.ruby-forum.com/u/nolic)\
**Post date:** [June 12, 2007, 6:48am UTC](https://www.ruby-forum.com/t/seo-in-radiant/106399/15 "2007-06-12T06:48:15Z")

</div>

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](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

---

<div class="post-metadata">

**Author:** ![nolic](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/13edae/32.png) [@nolic](https://www.ruby-forum.com/u/nolic)\
**Post date:** [June 12, 2007, 5:54am UTC](https://www.ruby-forum.com/t/seo-in-radiant/106399/16 "2007-06-12T05:54:28Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![nolic](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/13edae/32.png) [@nolic](https://www.ruby-forum.com/u/nolic)\
**Post date:** [June 12, 2007, 9:40am UTC](https://www.ruby-forum.com/t/seo-in-radiant/106399/17 "2007-06-12T09:40:54Z")

</div>

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](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](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.

---

<div class="post-metadata">

**Author:** ![nolic](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/13edae/32.png) [@nolic](https://www.ruby-forum.com/u/nolic)\
**Post date:** [June 12, 2007, 1:38pm UTC](https://www.ruby-forum.com/t/seo-in-radiant/106399/18 "2007-06-12T13:38:47Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![nolic](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/13edae/32.png) [@nolic](https://www.ruby-forum.com/u/nolic)\
**Post date:** [June 12, 2007, 4:49pm UTC](https://www.ruby-forum.com/t/seo-in-radiant/106399/19 "2007-06-12T16:49:53Z")

</div>

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](http://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](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

---

<div class="post-metadata">

**Author:** ![nolic](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/13edae/32.png) [@nolic](https://www.ruby-forum.com/u/nolic)\
**Post date:** [June 12, 2007, 4:57pm UTC](https://www.ruby-forum.com/t/seo-in-radiant/106399/20 "2007-06-12T16:57:47Z")

</div>

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

[Next page](https://www.ruby-forum.com/t/seo-in-radiant/106399.md?page=2)
