Why relative URLs should be forbidden for web developers

Thanks for the post Yoast.

I would like to also voice my like for ScreamingFrog – it’s an invaluable tool to have in the kit and I’ve been using it happily for years.

Great for doing reconnaissance on client sites that have ‘issues’.

I’m kinda a beginner to wordpress, but it appears that the default menu feature (Appearance > Menus) outputs relative URLs. Is this what your talking about as a no-no? Is there any way I can change this default behavior so all URLs are outputted in full? (ie http://www.stridepestcontrol.com/services/ instead of /services/) Thanks for the great article.

For those who want to do a “search and replace” of URLs because you are developing on a test, I have a PHP script here that we developed at Choice OMG. It basically replaces every instance of an old URL with a new one.

[code lang=”php”]<?php
$user="username";
$password="password";
$database="database";
mysql_connect(localhost,$user,$password);
@mysql_select_db($database) or die( "Unable to select database");

$oldurl = "dev.choiceomg.com";
$newurl = "www.choiceomg.com";

$query = "SELECT post_content, id from wp_posts where post_content LIKE ‘%$oldurl%’";
$result = mysql_query($query);
$num=mysql_numrows($result);

$i=0;
while ($i < $num) {

$id = mysql_result($result, $i ,"id");
$post_content =mysql_result($result,$i,"post_content");
$post_content = mysql_real_escape_string(preg_replace("/$oldurl/", "$newurl", $post_content));

$q = "UPDATE wp_posts set post_content = ‘$post_content’ where id = $id";
//var_dump($q);
mysql_query($q);

$i++;

}

$query = "SELECT guid, id from wp_posts where guid LIKE ‘%$oldurl%’";
$result = mysql_query($query);
$num=mysql_numrows($result);

$i=0;
while ($i < $num) {

$id = mysql_result($result, $i ,"id");
$post_content =mysql_result($result,$i,"guid");
$post_content = mysql_real_escape_string(preg_replace("/$oldurl/", "$newurl", $post_content));

$q = "UPDATE wp_posts set guid = ‘$post_content’ where id = $id";
//var_dump($q);
mysql_query($q);

$i++;

}

$query = "SELECT meta_id, meta_value from wp_postmeta where meta_value LIKE ‘%$oldurl%’";
$result = mysql_query($query);
$num=mysql_numrows($result);

$i=0;
while ($i < $num) {

$id = mysql_result($result, $i ,"meta_id");
$post_content =mysql_result($result,$i,"meta_value");
// check if it’s serialized
$post_arr = unserialize($post_content);
if ($post_arr === false)
$post_content = mysql_real_escape_string(preg_replace("/$oldurl/", "$newurl", $post_content));
else {
// its unserializable, iterate through all of array and replace each item
foreach ($post_arr as $key => &$item) {
$item = mysql_real_escape_string(preg_replace("/$oldurl/", "$newurl", $item));
}

$post_content = serialize($post_arr);

}
$q = "UPDATE wp_postmeta set meta_value = ‘$post_content’ where meta_id = $id";
//var_dump($q);
mysql_query($q);

$i++;

}

$query = "SELECT option_id, option_value from wp_options where option_value LIKE ‘%$oldurl%’";
$result = mysql_query($query);
$num=mysql_numrows($result);

var_dump($num);
$i=0;
while ($i < $num) {

$id = mysql_result($result, $i ,"option_id");
$post_content =mysql_result($result,$i,"option_value");
// check if it’s serialized
$post_arr = unserialize($post_content);
if ($post_arr === false)
$post_content = mysql_real_escape_string(preg_replace("/$oldurl/", "$newurl", $post_content));
else {
// its unserializable, iterate through all of array and replace each item
foreach ($post_arr as $key => &$item) {
$item = mysql_real_escape_string(preg_replace("/$oldurl/", "$newurl", $item));
}

$post_content = serialize($post_arr);

}
$q = "UPDATE wp_options set option_value = ‘$post_content’ where option_id = $id";
mysql_query($q);

$i++;
}[/code]

I disagree. You’re making assumptions that simply aren’t true. For example, you claim that using relative URLs is the cause of the problem in this case. That’s not true, and in fact, is a saving grace for Twitter in several other ways.

First and foremost, you must understand *why* Twitter (or any other site) would do this. The answer is to be more universally accessible. Twitter has fought hard to preserve it’s availability in countries where sharing opinions can be a crime. In China, India, Hong Kong, Germany, and other countries there are literally thought crimes for voicing dissent or posting information contrary to the govt approved position. In the past, countries have prevented access to sites (including Twitter and Facebook) simply as a matter of preventing discussion or even citizen awareness of events like the Wang Lijun situation earlier this year. To prevent this censorship, which is usually effected by a DNS filter, Twitter is available via it’s IP addresses directly. However, in doing so, it’s important that the site remain navigable, which is only accessible via relative URLs *or* if the absolute URL outputted to the client includes the IP address instead of the domain name. Either option is acceptable and fully functional, but the absolute URL method requires more server resources.

The issue here isn’t a matter of the relative URLs used being the problem, but rather that the canonical URL that Twitter is pushing *does* include the absolute URL, including the active domain or IP address instead of ‘twitter.com’. This is bad code, plain and simple. The problem you’re complaining about isn’t being caused by relative URLs, but invalid canonical links.

Even so, I’ve always believed it’s bad form to use relative URLs with dot-syntax, and encourage developers to use root-relative URLs or absolute URLs whenever possible. As you aptly described above, way too much can go wrong with the dot-syntax to rely on it for either proper linking or bots, which typically can’t be trusted to parse the URLs correctly.

Great Article Joost..Thanks for sharing..:)
Lastly, never heard of Screaming Frog ,Looking forward to use this tool.

I always use relative links to the root to avoid spider traps. I see that you mention this is also problematic, so to clarify, is an automated system also prone to user error (one that would add the server name in each relative link)? so are you advocating using some automated script that will replace a test domain to the main domain while publishing?

In the part about why relative URLs are still used, I think you missed the real argument on why they are “faster”. It doesn’t have to do with them being shorter, it is about DNS lookups on the client browser. Permalinks/aboslute URLs in the past required a DNS lookup for each one, slowing page loading by a little bit (depending on the speed of the end user’s DNS). Relative URLs didn’t (in the past) cause this.

I believe most browers cache DNS results now, so it’s a moot point. And, even if they don’t the small difference and does not make up for the fact that relative URLs cause all sorts of issues.

For a canonical or base href, I’d always recommend a full URL. But if those are correct I actually think it’s quite difficult for even a semi-competent developer to screw up standard internal relative links, even on a large site.

The issue isn’t relative links themselves; it’s people using them incorrectly. So I don’t agree usage should be stopped and I can’t see support for relative links being dropped by engines etc any time soon.

I see plenty of sites with bad header redirects or poorly implemented URL rewriting; that doesn’t mean header redirects and URL rewriting should be forbidden!

Just my opinion though; if I’d seen as many sites as you probably have with this issue, I might change my mind :)

Thanks for the tip Yoast…I’m not a Developer but I believed that relative URL will put less load on Server… Thanks for clarification and it will make a huge difference here..

Mmm,
I’m not really sure this is the case for all the options in the post.

The issues you talk about in “A completely indexed test environment” and “Spider traps” and issues that can happen with relative or absolute URLs. The issue is connected to an error and an error can be made in both cases.
If you can miss a dot in “./contact” you can also miss a dot in “http://wwwexample.com/”, don’t you?

I agree regarding the canonical URL. If we identify the perfect page where the canonical should point, we need to use the complete path, and not a relative URL, BUT I don’t agree on the solution you propose for it.
Make a 301 redirect for all the canonical URL is going to be a problem in all the case where your contenct is prety much the same BUT something is different: take as an example the famous e-commerce website with the same shoes and the same content, but with dirrerent colours. If I apply a 301 redirect to my “perfect page” if a visitor try to see the blue-shoes page (same content and linked with a canonical to the perfect page), he will be redirected to the canonical…

Am I completely wrong or I got some points?

Indeed it does. And when they promise that the dev environment never gets passed the firewall and proxy. How come that ww2. and dev. are indexed?

Really familiar.
Yesterday I discovered KLM used this as well.
Klm.com vs klmpinata.com :-)

Its just a matter of time now to have their search results screwed up.