redirect / new website how to redirect old (google) links to newsite ?

[John]

Hi,

I updated a site and changed the file extensions from .html to .php.

Now i noticed that the google does find the old .html pages but since
they're not there anymore... they can't be found.

Are there any way of (easily, without messing the site ;)) redirecting
those links to the main site?

Thanks!

[Jerry Stuckle]

Re: redirect / new website how to redirect old (google) links tonew site ?

John wrote:

Hi,
>
I updated a site and changed the file extensions from .html to .php.
>
Now i noticed that the google does find the old .html pages but since
they're not there anymore... they can't be found.
>
Are there any way of (easily, without messing the site ;)) redirecting
those links to the main site?
>
Thanks!

John,

This is an Apache (or whatever webserver you're using) question, not a
PHP one.

If you're using Apache, try alt.apache.conf iguration.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[Michael Fesser]

Re: redirect / new website how to redirect old (google) links to new site ?

..oO(John)

>I updated a site and changed the file extensions from .html to .php.

Read

Cool URIs don't change

http://www.w3.org/Provider/Style/URI

>Now i noticed that the google does find the old .html pages but since
>they're not there anymore... they can't be found.
>
>Are there any way of (easily, without messing the site ;)) redirecting
>those links to the main site?

Don't redirect. Configure your server to parse .html files for PHP.

Micha

[John]

Re: redirect / new website how to redirect old (google) links tonew site ?

Thanks!!

Michael Fesser kirjoitti:

.oO(John)
>

>I updated a site and changed the file extensions from .html to .php.

>
Read
>
Cool URIs don't change

http://www.w3.org/Provider/Style/URI

>

>Now i noticed that the google does find the old .html pages but since
>they're not there anymore... they can't be found.
>>
>Are there any way of (easily, without messing the site ;)) redirecting
>those links to the main site?

>
Don't redirect. Configure your server to parse .html files for PHP.
>
Micha

[Jerry Stuckle]

Re: redirect / new website how to redirect old (google) links tonew site ?

Michael Fesser wrote:

.oO(John)
>
>

>>I updated a site and changed the file extensions from .html to .php.

>
>
Read
>
Cool URIs don't change

http://www.w3.org/Provider/Style/URI

>
>

>>Now i noticed that the google does find the old .html pages but since
>>they're not there anymore... they can't be found.
>>
>>Are there any way of (easily, without messing the site ;)) redirecting
>>those links to the main site?

>
>
Don't redirect. Configure your server to parse .html files for PHP.
>
Micha

It's unnecessary overhead to parse static html files for PHP code. Now
what if you also want server side includes? And maybe another language
or two? A 301 redirect is recognized by all search engines and they
will replace the old URL with the new one.

New users will get the new URI and old ones will get redirected (and
most will also quickly learn the new URI).

After a period of time, you can replace the 301 redirect with another
page which indicates "The page has moved...". That way the few
left-over people who haven't change the URI will do so.

And BTW - I wouldn't classify a URI as "cool" just because it had an
html extension.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[John Dunlop]

Re: redirect / new website how to redirect old (google) links to new site ?

Jerry Stuckle:

And BTW - I wouldn't classify a URI as "cool" just because it had an
html extension.

No, neither would I, but did you actually read /Cool URIs don't
change/? Read it and you'll see that that's not what Michael meant.

--
Jock

[Michael Fesser]

Re: redirect / new website how to redirect old (google) links to new site ?

..oO(Jerry Stuckle)

>Michael Fesser wrote:

>>
>Don't redirect. Configure your server to parse .html files for PHP.

>
>It's unnecessary overhead to parse static html files for PHP code.

His files are not static, they contain PHP code. It's the URL that
should be static to avoid link rot and inconveniences for your visitors.

Now
>what if you also want server side includes?

If you have PHP, you don't need SSI anymore.

But of course you can also use SSI if you like - just configure the
server to parse .html files for SSI directives. And if you want to use
it all at the same time, you can do that as well:

http://example.com/static.html

http://example.com/phpscript.html

http://example.com/perlscript.html

http://example.com/ssi.html

It just depends on the server configuration (in this case for example
with content negotiation and MultiViews).

>A 301 redirect is recognized by all search engines and they
>will replace the old URL with the new one.
>
>New users will get the new URI and old ones will get redirected (and
>most will also quickly learn the new URI).

That's a broken design. There are many valid reasons to keep all such
technical stuff out of URLs.

>After a period of time, you can replace the 301 redirect with another
>page which indicates "The page has moved...". That way the few
>left-over people who haven't change the URI will do so.

Completely unnecessary, if you do it right from the beginning. If you
really think you need a filename extension in URLs, then use 'html'.
Of course no extension at all is even better.

Micha

[Jerry Stuckle]

Re: redirect / new website how to redirect old (google) links tonew site ?

John Dunlop wrote:

Jerry Stuckle:
>
>

>>And BTW - I wouldn't classify a URI as "cool" just because it had an
>>html extension.

>
>
No, neither would I, but did you actually read /Cool URIs don't
change/? Read it and you'll see that that's not what Michael meant.
>

Yep, I read it. And I disagree with a lot of what it said.

It's ok to have a "cool" url such as www.example.com/john/...

That I wouldn't necessarily want to change. But just changing .html
extensions to .php? Not even two seconds thinking about it.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[Jerry Stuckle]

Re: redirect / new website how to redirect old (google) links tonew site ?

Michael Fesser wrote:

.oO(Jerry Stuckle)
>
>

>>Michael Fesser wrote:
>>

>>>Don't redirect. Configure your server to parse .html files for PHP.

>>
>>It's unnecessary overhead to parse static html files for PHP code.

>
>
His files are not static, they contain PHP code. It's the URL that
should be static to avoid link rot and inconveniences for your visitors.
>

Not necessarily. I have customers with a lot of PHP files which are
pretty much 'static'. Many of them depend on stuff in databases which
might change once a year or less. Not a lot of difference there between
a static page which is updated once a year and one which pulls from a
database.

Also, I have some customers with .php pages which really are static.
But why use PHP for some other function such as processing form data.
The output doesn't change at all. In that sense, they are 'static'.

Also, he never said *all* his pages were static. Telling the web server
to process *all* .html files as php files is an unnecessary overhead.

>

>Now
>>what if you also want server side includes?

>
>
If you have PHP, you don't need SSI anymore.
>

And if you don't need any PHP code in the page other than maybe an
include, you're doing completely unnecessary work.

But of course you can also use SSI if you like - just configure the
server to parse .html files for SSI directives. And if you want to use
it all at the same time, you can do that as well:
>

http://example.com/static.html

http://example.com/phpscript.html

http://example.com/perlscript.html

http://example.com/ssi.html

>
It just depends on the server configuration (in this case for example
with content negotiation and MultiViews).
>

Yep, and the more you tell the server it has to parse, the more CPU time
it takes.

>

>>A 301 redirect is recognized by all search engines and they
>>will replace the old URL with the new one.
>>
>>New users will get the new URI and old ones will get redirected (and
>>most will also quickly learn the new URI).

>
>
That's a broken design. There are many valid reasons to keep all such
technical stuff out of URLs.
>

Not at all. No "technical stuff" in the url at all. You're just
redirecting index.html to actually retrieve index.php instead. And the
latter will be processed by the php interpreter.

>

>>After a period of time, you can replace the 301 redirect with another
>>page which indicates "The page has moved...". That way the few
>>left-over people who haven't change the URI will do so.

>
>
Completely unnecessary, if you do it right from the beginning. If you
really think you need a filename extension in URLs, then use 'html'.
Of course no extension at all is even better.
>
Micha

No extension? UGH - no, DOUBLE UGH! Vomit! Wash your mouth out with soap!

Extensions were created for a purpose - to let the server know what
needs to be handled by which processors. To bypass that creates a
completely unnecessary load on the server.


--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[Michael Fesser]

Re: redirect / new website how to redirect old (google) links to new site ?

..oO(Jerry Stuckle)

>Michael Fesser wrote:
>
>Also, I have some customers with .php pages which really are static.
>But why use PHP for some other function such as processing form data.

There are many more nice things I use PHP for, even if the output may be
static (for a while). If I can use a tool and get some benefits from it,
I use it.

>Also, he never said *all* his pages were static. Telling the web server
>to process *all* .html files as php files is an unnecessary overhead.

Who cares? That's what a server is for. You won't be able to notice a
difference in time between a plain HTML file delivered as-is and another
HTML file, parsed by PHP. Even with PHP-(Fast)CGI the difference is too
small. The transfer over the network takes much more time.

And BTW: Unnecessary 301 redirects are no overhead? Not much for the
server, but for all the clients and the network.

>But of course you can also use SSI if you like - just configure the
>server to parse .html files for SSI directives. And if you want to use
>it all at the same time, you can do that as well:
>>
>http://example.com/static.html
>http://example.com/phpscript.html
>http://example.com/perlscript.html
>http://example.com/ssi.html
>>
>It just depends on the server configuration (in this case for example
>with content negotiation and MultiViews).
>>

>Yep, and the more you tell the server it has to parse, the more CPU time
>it takes.

That's his job.

>That's a broken design. There are many valid reasons to keep all such
>technical stuff out of URLs.
>>

>Not at all. No "technical stuff" in the url at all. You're just
>redirecting index.html to actually retrieve index.php instead.

A 'php' in the URL is technical stuff that doesn't belong there. A URL
describes a resource, not details about the way it is generated.

>No extension?

Exactly. Reliable, long-living (in other words: "cool") URLs don't need
an extension, simply because it avoids a lot of problems.

>UGH - no, DOUBLE UGH! Vomit! Wash your mouth out with soap!
>
>Extensions were created for a purpose - to let the server know what
>needs to be handled by which processors.

Concepts like "directory" , "file", "extension" don't exist in URLs.
A URL doesn't describe a file, but a resource.

You only need an extension if you directly map a URL onto the server's
filesystem. That's the most common, but not the only way. Of course on
the server the files still have their extension, but there's no need to
show it in a URL.

>To bypass that creates a
>completely unnecessary load on the server.

If your server gets into trouble because of some little lookups and
simple pattern matching then you have a _real_ problem.

You should care more about your clients (users, search engines) than
about the server and make things as easy as possible for them. Using the
right tools at the right time to satisfy the clients, that's the whole
point. Ignoring these tools just because they may cause some more CPU
load now and then is - sorry - stupid (no offense intended).

Micha

[Jerry Stuckle]

Re: redirect / new website how to redirect old (google) links tonew site ?

Michael Fesser wrote:

.oO(Jerry Stuckle)
>
>

>>Michael Fesser wrote:
>>
>>Also, I have some customers with .php pages which really are static.
>>But why use PHP for some other function such as processing form data.

>
>
There are many more nice things I use PHP for, even if the output may be
static (for a while). If I can use a tool and get some benefits from it,
I use it.
>
>

>>Also, he never said *all* his pages were static. Telling the web server
>>to process *all* .html files as php files is an unnecessary overhead.

>
>
Who cares? That's what a server is for. You won't be able to notice a
difference in time between a plain HTML file delivered as-is and another
HTML file, parsed by PHP. Even with PHP-(Fast)CGI the difference is too
small. The transfer over the network takes much more time.
>

Your hosting company, for one, unless you're on a dedicated server.
You're needlessly taking cpu cycles away from other sites on the server.

And BTW: Unnecessary 301 redirects are no overhead? Not much for the
server, but for all the clients and the network.
>

Very little compared to unnecessarily parsing .html files. mod_redirect
is quite short and quick in its operation - especially if the redirect
is in the httpd.conf file. But even in .htaccess it's quite fast.

>

>>>But of course you can also use SSI if you like - just configure the
>>>server to parse .html files for SSI directives. And if you want to use
>>>it all at the same time, you can do that as well:
>>>
>>>http://example.com/static.html
>>>http://example.com/phpscript.html
>>>http://example.com/perlscript.html
>>>http://example.com/ssi.html
>>>
>>>It just depends on the server configuration (in this case for example
>>>with content negotiation and MultiViews).
>>>

>>
>>Yep, and the more you tell the server it has to parse, the more CPU time
>>it takes.

>
>
That's his job.
>

And it's just plain sloppy programming or laziness to force it to do
more than is called for in a case like this.

>

>>>That's a broken design. There are many valid reasons to keep all such
>>>technical stuff out of URLs.
>>>

>>
>>Not at all. No "technical stuff" in the url at all. You're just
>>redirecting index.html to actually retrieve index.php instead.

>
>
A 'php' in the URL is technical stuff that doesn't belong there. A URL
describes a resource, not details about the way it is generated.
>

That may be your opinion. The extension just allows the server to do
the most efficient processing of the file. You could call it .xyz for
all I care - just set up the correct file type in Apache.

>

>>No extension?

>
>
Exactly. Reliable, long-living (in other words: "cool") URLs don't need
an extension, simply because it avoids a lot of problems.
>

Then your definition of "cool" varies from almost all of the rest of the
world. How many sites do you see with no extensions, for instance
(other than your own, of course).

>

>>UGH - no, DOUBLE UGH! Vomit! Wash your mouth out with soap!
>>
>>Extensions were created for a purpose - to let the server know what
>>needs to be handled by which processors.

>
>
Concepts like "directory" , "file", "extension" don't exist in URLs.
A URL doesn't describe a file, but a resource.
>

Yep, it describes a resource. One of the types of resource it describes
is a file. And when it's referring to a file on a server, the extension
is important. Not only .php, but things like .gif, .png, and others
come to mind.

You only need an extension if you directly map a URL onto the server's
filesystem. That's the most common, but not the only way. Of course on
the server the files still have their extension, but there's no need to
show it in a URL.
>

No, it's not the *only* way. But it's the most common - AND THE MOST
EFFICIENT.

>

>>To bypass that creates a
>>completely unnecessary load on the server.

>
>
If your server gets into trouble because of some little lookups and
simple pattern matching then you have a _real_ problem.
>

Yep. You have a problem because you create unnecessary load on the server.

You should care more about your clients (users, search engines) than
about the server and make things as easy as possible for them. Using the
right tools at the right time to satisfy the clients, that's the whole
point. Ignoring these tools just because they may cause some more CPU
load now and then is - sorry - stupid (no offense intended).
>
Micha

I do care about my clients - especially the users. And the search
engines handle 301 redirects quite handily - as I have mentioned before.

And I do use the right tools at the right time. That's why I tell
Apache to parse .php files for PHP code, and not to parse .html files
for it.

And expecting the server to do your work for you is just plan lazy.
Sorry if it offends you - but that's how I see it.

Now - one other thing. You may get by with this on a site with 20 pages
and 1K hits/day. But try sites with 10K+ pages, and over 1M hits/hr.

There is a huge difference in the processing time required.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[John Dunlop]

Re: redirect / new website how to redirect old (google) links to new site ?

Jerry Stuckle:

[A URL] describes a resource.

Well, URLs by definition _locate_ network locatable resources,
specifically 'information resources', as one W3C Recommendation calls
them; whether or not the string of characters in a URL describes in
some human-recognisable way the resource it points to is up to you the
URL owner.

One of the types of resource it describes is a file.

The crux of the matter is that if a URL points to a particular
representation of a resource - e.g., HTML, XHTML, plain text, RTF - and
this is reflected in the URL in the shape of suffixes, when you change
the representation or add another representation and negotiate between
them you have to change the URL to keep it meaningful. For example, if
you originally publish a restaurant menu in plain text, ending its URL
path with '.txt', but later publish an HTML version and negotiate
between the two, the '.txt' at the end of the URL path is counter
intuitive for the HTML version.

You could solve this in one of two ways. One, publish two different
URLs, one ending in '.txt', the other in '.html'. However, this
undermines the value of the resource since it divides the community
into those who refer to the plain text version and those who refer to
the HTML version while for everyone the resource is conceptually a
single entity; c.f., Metcalfe's Law. Two, instead of seeing the URL as
pointing to a particular representation of the resource, see the URL as
pointing to the resource itself - the menu in the example above. That
way, when you change or add representations , you don't need to change
the URL because it identifies the resource itself rather than any
particular representation. Which way you choose depends on what you
see the URL as pointing to.

If you choose the second way, URL suffixes have no place in URLs
because they add nothing to the identification of the resource and they
run afoul of the principles of length (shortness), meaningfulness, and
persistency. I regard as weak the counter argument that if URL
suffixes are a de facto standard, then all URLs should include them.
The BBC, for example, publishes URLs without suffixes, and URLs without
suffixes occur in traditional media. Even if URL suffixes are a de
facto standard, the suffix-less ones are more user friendly.

--
Jock

[Jerry Stuckle]

Re: redirect / new website how to redirect old (google) links tonew site ?

John Dunlop wrote:

Jerry Stuckle:
>
>

>>[A URL] describes a resource.

>
>
Well, URLs by definition _locate_ network locatable resources,
specifically 'information resources', as one W3C Recommendation calls
them; whether or not the string of characters in a URL describes in
some human-recognisable way the resource it points to is up to you the
URL owner.
>
>

>>One of the types of resource it describes is a file.

>
>
The crux of the matter is that if a URL points to a particular
representation of a resource - e.g., HTML, XHTML, plain text, RTF - and
this is reflected in the URL in the shape of suffixes, when you change
the representation or add another representation and negotiate between
them you have to change the URL to keep it meaningful. For example, if
you originally publish a restaurant menu in plain text, ending its URL
path with '.txt', but later publish an HTML version and negotiate
between the two, the '.txt' at the end of the URL path is counter
intuitive for the HTML version.
>
You could solve this in one of two ways. One, publish two different
URLs, one ending in '.txt', the other in '.html'. However, this
undermines the value of the resource since it divides the community
into those who refer to the plain text version and those who refer to
the HTML version while for everyone the resource is conceptually a
single entity; c.f., Metcalfe's Law. Two, instead of seeing the URL as
pointing to a particular representation of the resource, see the URL as
pointing to the resource itself - the menu in the example above. That
way, when you change or add representations , you don't need to change
the URL because it identifies the resource itself rather than any
particular representation. Which way you choose depends on what you
see the URL as pointing to.
>
If you choose the second way, URL suffixes have no place in URLs
because they add nothing to the identification of the resource and they
run afoul of the principles of length (shortness), meaningfulness, and
persistency. I regard as weak the counter argument that if URL
suffixes are a de facto standard, then all URLs should include them.
The BBC, for example, publishes URLs without suffixes, and URLs without
suffixes occur in traditional media. Even if URL suffixes are a de
facto standard, the suffix-less ones are more user friendly.
>

As I said - I see it pointing to a resource. But one size does not fit
all. There are different types of resources on the internet.

For instance, all of my printers are tcp/ip ready. All of them have
URI's associated with them, and I print to a URI. But I don't try to
load one in my browser - it's the wrong type. I also have system
backups on an internet server. These are also URI's - but I wouldn't
load one in a browser. And my email servers are another type of URI.

When dealing with file URI's, the file extension is meaningful. Maybe
not to the user, but definitely to the server. Servers make different
decisions on how to handle different file extensions for performance
reasons. You wouldn't want to try to run a .asp file through a .php
parser, for instance. And you wouldn't want to try to run everything
(including static pages) through both. It would bring any reasonably
active server to its knees.

Theory is good. And it even works in low volume sites on low activity
servers. But the overhead quickly becomes more unmanageable in more
heavily used sites. I find ignoring this fact to stick to an ideal is a
very weak argument.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[John Dunlop]

Re: redirect / new website how to redirect old (google) links to new site ?

Jerry Stuckle:

When dealing with file URI's, the file extension is meaningful.

Frankly, Jerry, I don't know whether to laugh or cry.

--
Jock

[Jerry Stuckle]

Re: redirect / new website how to redirect old (google) links tonew site ?

John Dunlop wrote:

Jerry Stuckle:
>
>

>>When dealing with file URI's, the file extension is meaningful.

>
>
Frankly, Jerry, I don't know whether to laugh or cry.
>

John, when you figure out, please let the rest of us know.

Theory is great. And if there were some way for the web server to
determine what type of file it is, it would be a different story.

But right now all we have (on Linux) is an executable flag. The file
can either be executed by the OS or not. There is no way for the web
server to determine what it needs to parse for various languages.

Let me give you an example from one site. Most of the site is written
in VBScript (.asp). However, we have a discussion forum written in
Perl. We have other packages written in PHP. And we're looking at
adding another package which requires Python.

Now - do you expect the webserver to parse every one of those files,
including the static pages, for VBScript, PHP, Perl and Python?

Right now the only way the web server can tell is by the file extension.
Of course this is on IIS, so there's no .htaccess. But I guess if you
dug deeply enough there might be a way to tell the server to parse
index.html as .asp code, but blog.html as PHP code and discussion.html
as Perl code.

Can you imagine the trouble trying to keep up with a couple of thousand
files like that?

This is the real world, not some theoretical Utopia.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===