Calendar
Network
Feeds
- 21
- Sphinn It!
Went Hot: August 22, 2007 - 12:46 pm
Posted By: Lyndon 380 days ago
Topic Type: News Story (Jump to http://www.seoco.co.uk)
Category: SEO
But what happens when things go wrong? Who you gonna call?
10 Comments
Comments
*** Documentation about a 301 redirect is thin on the ground. ***
I'm not sure where you have been looking, but there are literally hundreds of thousands of forum posts and tutotrials about this subject.
The subject has been covered daily, or even several times daily, for at least several years, in some of them.
"I'm not sure where you have been looking, but there are literally hundreds of thousands of forum posts and tutotrials about this subject.
The subject has been covered daily, or even several times daily, for at least several years, in some of them."
I couldn't work out how to set one up on the Windows hosted site, neither could the web host, I don't know if it was even possible for that one.
"I couldn't work out how to set one up on the Windows hosted site, neither could the web host, I don't know if it was even possible for that one."
1) Open IIS Manager
2) Right click on the desired website and select "properties"
3) Click on the "Home Directory" tab
4) Where it says "When connecting to this resource, the content should come from" select the "A redirection to a URL" button.
5) Enter the URL in the "Redirect to" box
6) Check the "A permanent redirection for this resource" box.
Presto! You've now got a shiny new 301 redirect using IIS.
I tried that but it said "This server does not support file changing permissions"
If you use Windows shared hosting, make sure the host supports a rewriting tool (e.g. ISAPI_Rewrite, IISRewrite, Mod_Rewrite, IIRF, etc...) If you host your own, there is no excuse for not having a rewrite utility.
If you're running an ASP.NET application, and are hosting yourself, then you should check out http://urlrewriter.net which is a fantastic open-source URL rewriting assembly for ASP.NET. You just have to tell IIS to map all requests to ASP.NET and you have full url rewriting and redirecting control from the application's web.config.
I recommend but do not do the actual implementation of 301 redirects and a lot of other technical tasks. I DO know that whatever seems quick and simple to a) Someone who did it once or even a few times with no problems OR b) Has the expertise to overcome any challenges encountered is NOT always simple when what usually works doesn't and you're NOT an expert.
I applaud those who take the time to provide potential solutions to those who reach out for assistance.
"If you use Windows shared hosting, make sure the host supports a rewriting tool (e.g. ISAPI_Rewrite, IISRewrite, Mod_Rewrite, IIRF, etc...) If you host your own, there is no excuse for not having a rewrite utility."
It was not my hosting account it was my clients (sometimes these things are out of my control), if shared hosting means that other sites are on the same FTP then thats what it had. I don't need any excuse.
Great help if you're running 301's
Canonical issues www.domain.com vs domain.com (linux servers)
rewritecond %{http_host} ^domain.com [nc]
rewriterule ^(.*)$ http://www.domain.com/$1 [r=301,nc]
Link Issues:
Use paths for internal page linking as opposed to strict page names. (i.e. link to / as opposed to /index.html) - this will help with strict page names being found on Search Engines.
That fixes the www and non-www problem.
Additional to that, you may have some or all of these to contend with:
- http vs. https
- optional port numbers (requests via proxy often include ports)
- multiple TLDs (.com and .co.uk for example)
- multiple domains (mis-spellings, type-ins, etc)
- multiple subdomains (not just www and non-www, but wildcards that resolve)
- missing trailing / on folders needs to be added
- capitalisation issues (maninly Windows / IIS servers)
- different parameter orders in different links
- additional parameters (e.g. print-friendly pages)
- multiple paths to the same content (a nightmare in most forum, blog, cart, and CMS software)
- log-in pages that should not be indexed
- pages that only show content when you are logged-in (bots cannot log in)
This only scratches the surface of the URL structure that you present to search engines...