SEO http versus www

[Alan Sparkes]

Probably a hornets nest here but was wondering whether it would be a good idea for a default in htaccess file  to redirect www rather than let Google  rank the same page with and without the domain prefix?

Something along the lines of:

#handle www

RewriteCond %{HTTP_HOST} ^domainname\.com$ [NC]

RewriteRule ^(.*)$ http://www. domainname.com/$1 [L,R=301]

----

Alan

[Louis Landry]

I'd be for having both rules in there commented out with a description so that someone could make a choice.  I don't think we should by default be just setting something like that in an htaccess file.

- Louis

--
Development Coordinator
Joomla! ... because open source matters.
http://www.joomla.org

[Gergő Erdősi]

I agree, it shouldn't be there by default. What if you are on a
subdomain? What if you are on localhost? There are many cases where it
would cause issues. But I'm fine with a commented out code.

--
Gergő Erdősi



2009/11/23 Louis Landry <louis....@joomla.org>:

[Amy Stephen]

The way I handled this in the Tamka 301 Redirect Componen was to make "No WWW" a Parameter choice. Then, when WWW is found, it's 301 redirected like any other specified link.

[Louis Landry]

That's fine, but it means you have to spawn a PHP process, load and initialize Joomla, and then execute your plugin/component's code just to do a redirect that is always the case.  Using an htaccess file means that it happens in apache, before any of those things would happen.  Easier on the server and faster for users.  In a really high traffic situation it wouldn't be ideal to be running all of those things through a PHP process.  You would potentially see a lot of blocking and chewing up of unnecessary memory.

- Louis

[Amy Stephen]

Well, Louis, the htaccess file can always override what is done inside of Joomla!. So, for folks who have that skillset and need that type of performance tweek, adding "No WWW" redirects internally will not prevent them from using those methods. Most users who want that SEO benefit might not have those skills or be worried about that little bit of slowdown.

++++

Looking at the new Redirect Plugin, I see you are trapping the error, and providing this capability for 404's, only.

I handled it a bit differently. Any URL could be entered as an old value, and then redirected using a 301 header, to a new URL. (This would handle incorrect names where the initial URL is already used, and therefore, wouldn't 404) I used a System Plugin and the onAfterInitialise function as part of a Router override. It checks to see if the Plugin parameter is set, and if the subdomain is WWW, it performs a 301 redirect.

We could use that same approach, add an onAfterInitialise function to the Redirect System Plugin and a new Redirect Component Parameter and do the same thing.

But, since this would be a core change, it might make more sense to treat it like the Global Configuration option "Force SSL" and redirect right inside of the JRouterSite Class.

++++

Now, Louis, I have a question.

The 404 redirects and the SSL redirect do not force the 301.

I believe we need to force a 301 header -- or -- I don't think we will get the SEO benefit we are after. The 301 in the header is what signals the Googles of the world that this is an intentional and permanent change, and they should update their records for the 404, accordingly.

I believe we need to set header and then end the application in the Redirect plugin (and should make this change in the JRouterSite class, as well.)

        header('Location: ' . htmlspecialchars( $redirectTo ), true, '301');

        $app = & JFactory::getApplication();
        $app->close();

Does that seem right to you?

++++

Just some ideas, if you are against the No WWW internally for reasons previously mentioned, there is no sense creating a patch. There are also a few ways it could be done and I'm not certain which method you'd prefer.

If you want a patch, let me know what you want, and I can try to do that.

Thanks.

[Louis Landry]

Hi Amy,

On Mon, Nov 23, 2009 at 2:59 PM, Amy Stephen <amyst...@gmail.com> wrote:

Well, Louis, the htaccess file can always override what is done inside of Joomla!. So, for folks who have that skillset and need that type of performance tweek, adding "No WWW" redirects internally will not prevent them from using those methods. Most users who want that SEO benefit might not have those skills or be worried about that little bit of slowdown.

So are we saying that most users who use joomla might not have the skills to edit an htaccess file?  In the past we have had htaccess files that people edited -- over different types of URL mechanisms if memory serves.

 

++++

Looking at the new Redirect Plugin, I see you are trapping the error, and providing this capability for 404's, only.

I handled it a bit differently. Any URL could be entered as an old value, and then redirected using a 301 header, to a new URL. (This would handle incorrect names where the initial URL is already used, and therefore, wouldn't 404) I used a System Plugin and the onAfterInitialise function as part of a Router override. It checks to see if the Plugin parameter is set, and if the subdomain is WWW, it performs a 301 redirect.

We could use that same approach, add an onAfterInitialise function to the Redirect System Plugin and a new Redirect Component Parameter and do the same thing.

But, since this would be a core change, it might make more sense to treat it like the Global Configuration option "Force SSL" and redirect right inside of the JRouterSite Class.

Ya, thats certainly different.  Thats much more like a custom sef url solution than what I built with redirect.  Redirect was initially built when I needed to handle missing articles in the www.joomla.org migration from Joomla 1.0 to 1.5.  What I needed it for was to redirect users from old pages that didn't exist anymore to new locations either on the existing site or at a new site.  The beauty of the way its designed now is that for most page loads there is literally no extra work done -- unless a 404 is encountered.  Changing to the way you describe would mean at least another database lookup and function call on every single page load.

 

++++

Now, Louis, I have a question.

The 404 redirects and the SSL redirect do not force the 301.

I believe we need to force a 301 header -- or -- I don't think we will get the SEO benefit we are after. The 301 in the header is what signals the Googles of the world that this is an intentional and permanent change, and they should update their records for the 404, accordingly.

I believe we need to set header and then end the application in the Redirect plugin (and should make this change in the JRouterSite class, as well.)

        header('Location: ' . htmlspecialchars( $redirectTo ), true, '301');

        $app = & JFactory::getApplication();
        $app->close();

Does that seem right to you?

I think you are missing something.  The plugin calls JApplication::redirect().  You can see it on line 68 of /plugins/system/redirect.php as of revision 13566.

$app->redirect($link->new_url);

Which if you look on line 342 of /libraries/joomla/application/application.php you will find:

if (headers_sent()) {

echo "<script>document.location.href='$url';</script>\n";

} else {

header('HTTP/1.1 301 Moved Permanently');

header('Location: ' . $url);

}

$this->close();

 

Which clearly sends a 301 if possible.  If you are talking about something else, then I'm sorry but I am misunderstanding you.

++++

Just some ideas, if you are against the No WWW internally for reasons previously mentioned, there is no sense creating a patch. There are also a few ways it could be done and I'm not certain which method you'd prefer.

If you want a patch, let me know what you want, and I can try to do that.

Thanks.

I'm certainly not the only voice here, if the release team wants it and you get it working and ready for the trunk then by all means, but its not something I personally would be working on.  I personally think that if someone wants that, uncommenting a line in a htaccess file and/or setting something in Google Webmaster Tools is easy and simple enough.

Cheers,

[Amy Stephen]

On Mon, Nov 23, 2009 at 8:25 PM, Louis Landry <louis....@joomla.org> wrote:

Hi Amy,

On Mon, Nov 23, 2009 at 2:59 PM, Amy Stephen <amyst...@gmail.com> wrote:

Well, Louis, the htaccess file can always override what is done inside of Joomla!. So, for folks who have that skillset and need that type of performance tweek, adding "No WWW" redirects internally will not prevent them from using those methods. Most users who want that SEO benefit might not have those skills or be worried about that little bit of slowdown.

So are we saying that most users who use joomla might not have the skills to edit an htaccess file?  In the past we have had htaccess files that people edited -- over different types of URL mechanisms if memory serves.

I'm in no position to say what "we" are saying, but certainly my experience has been the less we have users mess with the htaccess file, the better off.

1.0 required some uncommenting and it did create forum activity. In 1.5, we didn't have changes there, and it was very helpful.

Might seem silly, but that's what I've seen.
 

 

++++

Looking at the new Redirect Plugin, I see you are trapping the error, and providing this capability for 404's, only.

I handled it a bit differently. Any URL could be entered as an old value, and then redirected using a 301 header, to a new URL. (This would handle incorrect names where the initial URL is already used, and therefore, wouldn't 404) I used a System Plugin and the onAfterInitialise function as part of a Router override. It checks to see if the Plugin parameter is set, and if the subdomain is WWW, it performs a 301 redirect.

We could use that same approach, add an onAfterInitialise function to the Redirect System Plugin and a new Redirect Component Parameter and do the same thing.

But, since this would be a core change, it might make more sense to treat it like the Global Configuration option "Force SSL" and redirect right inside of the JRouterSite Class.

Ya, thats certainly different.  Thats much more like a custom sef url solution than what I built with redirect.  Redirect was initially built when I needed to handle missing articles in the www.joomla.org migration from Joomla 1.0 to 1.5.  What I needed it for was to redirect users from old pages that didn't exist anymore to new locations either on the existing site or at a new site.  The beauty of the way its designed now is that for most page loads there is literally no extra work done -- unless a 404 is encountered.  Changing to the way you describe would mean at least another database lookup and function call on every single page load.

 

Agree. Certainly not asking for this to change.
 

 

++++

Now, Louis, I have a question.

The 404 redirects and the SSL redirect do not force the 301.

I believe we need to force a 301 header -- or -- I don't think we will get the SEO benefit we are after. The 301 in the header is what signals the Googles of the world that this is an intentional and permanent change, and they should update their records for the 404, accordingly.

I believe we need to set header and then end the application in the Redirect plugin (and should make this change in the JRouterSite class, as well.)

        header('Location: ' . htmlspecialchars( $redirectTo ), true, '301');

        $app = & JFactory::getApplication();
        $app->close();

Does that seem right to you?

I think you are missing something.  The plugin calls JApplication::redirect().  You can see it on line 68 of /plugins/system/redirect.php as of revision 13566.

$app->redirect($link->new_url);

Which if you look on line 342 of /libraries/joomla/application/application.php you will find:

if (headers_sent()) {

echo "<script>document.location.href='$url';</script>\n";

} else {

header('HTTP/1.1 301 Moved Permanently');

header('Location: ' . $url);

}

$this->close();

 

Which clearly sends a 301 if possible.  If you are talking about something else, then I'm sorry but I am misunderstanding you.

Nope, should have followed that thru. Thanks for your time on that.
 

++++

Just some ideas, if you are against the No WWW internally for reasons previously mentioned, there is no sense creating a patch. There are also a few ways it could be done and I'm not certain which method you'd prefer.

If you want a patch, let me know what you want, and I can try to do that.

Thanks.

I'm certainly not the only voice here, if the release team wants it and you get it working and ready for the trunk then by all means, but its not something I personally would be working on.  I personally think that if someone wants that, uncommenting a line in a htaccess file and/or setting something in Google Webmaster Tools is easy and simple enough.

OK. Sounds good. Thanks!
 

[nakham]

Very good idea. I propose commented lines in .htaccess by default.
Something like this

#RewriteCond %{HTTP_HOST} ^domain\.com$ [NC]
#RewriteCond %{REQUEST_URI} !^/robots\.txt$
#RewriteRule ^(.*)$ http://www.domain.com/$1 [R=301,L]

The second line is just for robots.txt which can use some extra
directives, like "Canonize-host" for example, for search engines

[Stephen]

Can I suggest a variant on this which takes care of even more cases.
Instead of checking for a particular variant of the domain name, check
for any string which is NOT the canonical domain name. It's not
uncommon for all subdomains to be re-routed to the main domain, then
all it takes is one mis-spelt link to your site to cause Google to
penalise you for duplicate content.

e.g.

#RewriteCond %{HTTP_HOST} !^www\.domain\.com$ [NC]

#RewriteCond %{REQUEST_URI} !^/robots\.txt$
#RewriteRule ^(.*)$http://www.domain.com/$1[R=301,L]

Cheers,
Stephen

On 24 Nov, 22:19, nakham <maxim.g...@gmail.com> wrote:
> Very good idea. I propose commented lines in .htaccess by default.
> Something like this
>
> #RewriteCond %{HTTP_HOST} ^domain\.com$ [NC]
> #RewriteCond %{REQUEST_URI} !^/robots\.txt$

> #RewriteRule ^(.*)$http://www.domain.com/$1[R=301,L]

[Stephen]

That should, of course, have had some more spaces in places:

#RewriteCond %{HTTP_HOST} !^www\.domain\.com$ [NC]
#RewriteCond %{REQUEST_URI} !^/robots\.txt$
#RewriteRule ^(.*) $http://www.domain.com/$1 [R=301,L]

Stephen

[nakham]

What about existing subdomains blog.domain.com or forum.domain.com? ;)
User will get redirect to www.domain.com in any case.

[Niels Braczek]

nakham schrieb:

> What about existing subdomains blog.domain.com or forum.domain.com? ;)
> User will get redirect to www.domain.com in any case.

Then you'll simply de-activate the rewrite rule.

Regards,
Niels

[Amy Stephen]

Is this redirecting to "www"?

Shouldn't we instead be offering an option to redirect to no "www" subdomain?

That's what I see as the industry standard, today -> http://no-www.org/

Doing it that way might also help with the problem of other, valid subdomains redirecting to www.

[Alan Sparkes]

Actually this makes plenty of sense to me Amy. Shorter URL string –three more characters, less typing.

 

[The original htaccess code I posted allows sub domains  fine on my server]

 

----

Alan

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.421 / Virus Database: 270.14.72/2511 - Release Date: 11/18/09 07:50:00

[Sam Moffatt]

.htaccess is good for those platforms that support it however not all
platforms support it and the rules it provides. In this particular
case not only do we need .htaccess but also mod_rewrite support.

Editing the file is a challenge for some people who would prefer to
just tick a box and make it all go away for them. I have an extension
that does just that because alledia on the forum asked if it could be
done for 1.6 or similar so I sat down and wrote something simple to do
it. I'm getting feature requests for the thing for specificity in
different situations (particularly mobile sites).

I agree with Louis is that every potential page hit to that location
is going to generate a PHP process. Though presuming things are
working fine what happens is that they land on the wrong page, it
directs them to the right page and they continue on their merry way.
Whilst not the most spectacular for performance the hit usually isn't
too bad. Crawlers start to ignore links to things they know are
redirects and you can tell Google which one is your primary, with or
without the WWW.

I don't see an issue including a line in the .htaccess for those who
want to add it. Mind you there are already tonnes of guides out there
for adding it. There are lots of little things we could put in and
some of which need to be treated with care. The problem I potentially
see is the fact that it is invisible. The person enabling might well
know where it is but what about the next person? This is where having
an extension actually makes sense. Someone might understand how to
disable a plugin but they might never think to look in the .htaccess
file to change something. Some of the comments on my own extension
mention that it is easier to use it and preferable than a .htaccess
file.

Other domains shouldn't be impacted unless they're landing on the same
location. So a blog or a forum should exist in their own directory and
you should have no impact on them with this .htaccess rule. So a catch
all for a domain should work fine.

Sam Moffatt
http://pasamio.id.au

[G. D. Speer]

Thanks for the link ....

This rewrite works beautifully to drop www from the URL - great for SEO as well.

Duke

 

RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,L]

No virus found in this incoming message.
Checked by AVG - www.avg.com

Version: 8.5.425 / Virus Database: 270.14.80/2523 - Release Date: 11/24/09 07:46:00