Forum Moderators: coopster

Message Too Old, No Replies

PHP way to dynamically generate rel=canonical

         

chewy

9:14 pm on Jun 17, 2015 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Hi,

This 2012 post

[webmasterworld.com...]

shows a way to elegantly generate a correct rel=canonical element dynamically for each page using the following PHP code:

<link rel="canonical" href="<?php $url="http://".$_SERVER['HTTP_HOST'].$_SERVER['SCRIPT_NAME'];echo $url;?>">

Is there any reason why this approach needs any update given this is 3 years old?

It looks to be working fine to me. But I'm not sure how I'd test it beyond just looking at the code behind the page.

However, as some of you may know, my copy/paste approach is sort of spray-and-pray and while it looks good to me, I have no way of truly knowing it is working the way it should.

Thanks!

-C

topr8

10:05 pm on Jun 17, 2015 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



i should have thought you could shorten it slightly to:

<?php echo "http://".$_SERVER['HTTP_HOST'].$_SERVER['SCRIPT_NAME'];?>


this will work assuming that the main url had had no querystring and any other variants of the page would have a query string, you are essentially just writing the URL minus any query string,
if there would be other variants of the URL then it would not be a suitable canonical url

topr8

10:02 am on Jun 18, 2015 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



oh and actually i had another thoguht on this ...

if you haven't sorted out the www. or non www. at the server level then you could be serving 2 different canonical values at different times


www.example.com/mypage

example.com/mypage


which are of coursedifferent url's altogether

(also in your case as you have hard coded http:// i assume you have not got a secure certificate on the site in question and are not concerned about potentially serving the same page from http and https)

whitespace

10:07 am on Jun 18, 2015 (gmt 0)

10+ Year Member Top Contributors Of The Month



If think "elegantly" is a bit debatable. ;) But if it works for you then that's great. Nothing has changed security-wise to warrant an update to the code.

Note, however, that this is not a one-stop fix for everyone's canonical URL issues. You should be aware of its limitations. As topr8 states, SCRIPT_NAME excludes any query string - which is often desirable for a canonical URL (but not necessarily). But also, SCRIPT_NAME is not strictly a URL at all - it's the root-relative filesystem path of the currently executing script. Likewise, it also excludes any trailing pathname information (if your server allows it). eg. a request for "http://example.com/path/to/file.php/foo/bar" returns "/path/to/file.php" (again this is usually desirable, but might not be).

If the requested URL maps directly to a filesystem path (which it will do by default) eg. a request for "http://example.com/path/to/file.php" returns the resource "/path/to/file.php" then yes, SCRIPT_NAME matches the URL.

However, if you are doing any kind of URL rewriting (pretty URLs, extensionless URLs etc) then SCRIPT_NAME is not going to work for you. eg. If a request for "http://example.com/category/article" is internally rewritten to "/path/to/file.php" then SCRIPT_NAME returns "/path/to/file.php", not "/category/article".