Search Engine Friendly URL conversion issues
We've set it up for search firendly url construction with the forum name incorporated into the url. We've set PGDRewrite.asp up as a custom 404 URL (defined as '/forum/PGDrewrite.asp'). When you go to click into a forum, the forum gets displayed, but the URL is not fully corrected in the address bar. Rather, it leaves the pre-new-URL address when I believe it should be stripping away everything from the 404 back.
instead of just: http://<oursite>/forum/General_Discussion/forumid_1/tt.htm A1:
Thanks to Quenton who found the solution to this issue:
we finally tracked a solution to this down on the web. It seems to be a "feautre" of how IIS handles .asp pages. The reason we got it on ASP Playground, when most people didn't, is that our server is set to execute .htm files as if they were .asp - probably yours is too!
Anyway, here's the fix for .asp files:
If you are being redirected to the custom 404 error handler and the URL looks similar to "/my404script.asp?404 http://www.example.com/foo.asp"), this is a bug to do with the way IIS handles certain extensions.
The fix is really simple and involves a single IIS configuration change which fixes this problem - although for what it's worth the intermediate redirect doesn't cause any problems with crawlers / search engine spiders.
1. Open the IIS Manager console.
2. Access the properties for your website.
3. Click the "Home Directory" tab.
5. Click the "configration" button.
6. Select ".asp" and click the "edit" button.
7. Ensure the "check file exists" checkbox is enabled.
Assuming you have HTM set to execute as ASP do this for both file types.
Also, ErEf mentioned that he saw a similar behavior on the ASP.NET version, and this is what he says:
I marked the checkbox check that file exists, and that solved the problem.
.aspx files are handled by v1.1.4322\aspnet_isapi.dll without the checking if the file exists.
It seems that when there's three periods in a row the forum redirect errors. Anybody seen this?
Looks like it only happens if you choose option 3...embed name into link.
After more testing it seems that if the name has any type of encoded character at the end, the redirect will break. A2:
If you are using an unmodified install of URLScan
, you'll have to turn off a few options to get the SEO rewrite to work properly.
post edited by Samuel -