I did some simple testing I've got a test node with name Case 1 with url /case-1/. When I rename it to Case 2 and I visit the /case-1/ it should to a 301 redirect to /case-2/. This works local, but not on the staging server. It's the exact same environment. On the staging it shows a 404 and the url never appears in redirect manager. What could be the problem?
Weird, but now it always gets picked up from there. Can you check if the pagename change is logged in urlHistory table also? The first time it should try to find the redirect based on that table.
We are using route-hijacking (Hybrid Framework), v7.2.6, SEO Checker 1.9.1.
The only way I can get it to work is by disabling both SEO Checkers and and Umbracos config, then it works but we get ugly default Umbraco 404 instead on not founds; any combination of turning on custom 404 and redirects stop working (get nice 404 instead).
I guess work around is to use IIS URL Rewrite module (adding rules manually), but we'd really like to get this working again.
then it works; turn them on again (either/or/both) and all redirects 404.
Update:
After further investigation:
Umbraco 7.2.5 with SEOChecker 1.8.1 works as expected; 7.2.6 with 1.8.1 (and higher) does not work; I've not been able to check < 7.2.6 with 1.9.1 yet.
Update 2:
Vanilla 7.2.6 without route hijacking works fine, will continue troubleshooting; any tips / advice appreciated.
Update 3:
Partially resolved now. Our default 404 page was returning HTTP 200 status code (via code).
However still having issues with some URL's, for example adding a manual entry results in 404 instead of redirect.
Hello,
I have the exact same problems and here are my setups/tests :
I have 2 sites, both Umbraco 7.2.8 and SeoChecker 1.9.1
The first one is doing the redirection correctly after renaming the node but not the second one.
After entering a url that should redirect, both add a line in "SEOChecker_PageNotFound" table but the one not working adds "0" in the DocumentID column.
AND it seems that the bug in the database and not the code/configuration. Let me explain why :
- I have plugged the not working site to the working database => I did not have the problem anymore
- I have plugged the working site to the not working database => the problem appears.
So the code and configurations seems OK. The problem seems in the database....
I have also try to empty all values of all SEOChecker tables in both projects and retest => same results.
I tried to use DotPeek to check the SeoChecker code (how it inserts the DocumentID column) but it's not really readable with dotPeek ;)
I'm out of ideas.. do you have any ideas, suggestions about how I should look at the problem ?
What are the sitemap.xml errors and is the redirect module running at all? I think you have an install issue. By the way 1.8.1 is a very old version please make sure to upgrade to the latets version also http://soetemansoftware.nl/seo-checker/downloads
Think you are using a V1.x version of SEOChecker? V2 creates the entries again. V1 had some performance issues so we dropped the renaming in that version.
After renaming the old url doesn't go to new url
Hello,
I did some simple testing I've got a test node with name Case 1 with url /case-1/. When I rename it to Case 2 and I visit the /case-1/ it should to a 301 redirect to /case-2/. This works local, but not on the staging server. It's the exact same environment. On the staging it shows a 404 and the url never appears in redirect manager. What could be the problem?
Jeroen
Hi Jeroen,
This is propably because your UrlModule is not running. Add the urlmodule to the web.config and all should be good I think.
Best,
Richard
Hi Richard,
The SEOCheckerUrlModule is part of the web.config and enabled.
Jeroen
SO the url appears in the Inbound link errors?
Yes it's in the inbound link errors.
Weird, but now it always gets picked up from there. Can you check if the pagename change is logged in urlHistory table also? The first time it should try to find the redirect based on that table.
It also get's logged into the URLHistory table. I just renamed it from case 8 to case 9. This is in the table:
UrlHistoryId NodeId ParentId UrlPart
136 2129 1472 case-8
Jeroen
Seeing same behaviour recently.
We are using route-hijacking (Hybrid Framework), v7.2.6, SEO Checker 1.9.1.
The only way I can get it to work is by disabling both SEO Checkers and and Umbracos config, then it works but we get ugly default Umbraco 404 instead on not founds; any combination of turning on custom 404 and redirects stop working (get nice 404 instead).
I guess work around is to use IIS URL Rewrite module (adding rules manually), but we'd really like to get this working again.
Can supply further info if required?
Thanks,
Gavin
Previous post did not show my XML; if we disable in 404handlers.config
and in SEOChecker.config turn notFoundConfig
then it works; turn them on again (either/or/both) and all redirects 404.
Update:
After further investigation:
Umbraco 7.2.5 with SEOChecker 1.8.1 works as expected; 7.2.6 with 1.8.1 (and higher) does not work; I've not been able to check < 7.2.6 with 1.9.1 yet.
Update 2:
Vanilla 7.2.6 without route hijacking works fine, will continue troubleshooting; any tips / advice appreciated.
Update 3:
Partially resolved now. Our default 404 page was returning HTTP 200 status code (via code).
However still having issues with some URL's, for example adding a manual entry results in 404 instead of redirect.
Hello, I have the exact same problems and here are my setups/tests :
I have 2 sites, both Umbraco 7.2.8 and SeoChecker 1.9.1
The first one is doing the redirection correctly after renaming the node but not the second one.
After entering a url that should redirect, both add a line in "SEOChecker_PageNotFound" table but the one not working adds "0" in the DocumentID column.
AND it seems that the bug in the database and not the code/configuration. Let me explain why : - I have plugged the not working site to the working database => I did not have the problem anymore - I have plugged the working site to the not working database => the problem appears.
So the code and configurations seems OK. The problem seems in the database.... I have also try to empty all values of all SEOChecker tables in both projects and retest => same results.
I tried to use DotPeek to check the SeoChecker code (how it inserts the DocumentID column) but it's not really readable with dotPeek ;)
I'm out of ideas.. do you have any ideas, suggestions about how I should look at the problem ?
Many thanks
Hello, Deleting the "http://" from my hostname (on the sitenode), solved my problem !
Hi Richard
Ravi Motha and I am experiencing the same issue with one of our websites.
Local is fine Live is not
Umbraco version is 7.2.8
SEO checker is 1.8.1
Are you able to help with this?
Thanks Scott
Hi,
What are the sitemap.xml errors and is the redirect module running at all? I think you have an install issue. By the way 1.8.1 is a very old version please make sure to upgrade to the latets version also http://soetemansoftware.nl/seo-checker/downloads
Best,
Richard
Thanks Richard
Redirects are working fine on local, and dev, but not on the client's server.
The IIS versions are identical. Windows 8, IIS version 8.5.9600.16384
We have checked configs and they are right.
We have the same issue on two sites on two different client servers. One of them has the latest SEOchecker version, so it's not that.
We're still investigating to see if there is a server related aspect to this, but if you have some thoughts, please let me know.
Thanks Scott
The same problem.!
I have picked a node using url picker and later i renamed that node name. But when clicking that url it redirected to old url.!
Anyone got the solution?
Hi,
what version? and does it creates redirects in the redirect overview?
Best,
Richard
Hi Richard,
Thanks for your time : )
I'm using Umbraco version 7.12.4 & assembly: 1.0.6879.21982
The click doesn't create any redirect entries in URL Management.!
Arun
Think you are using a V1.x version of SEOChecker? V2 creates the entries again. V1 had some performance issues so we dropped the renaming in that version.
Best,
Richard
is working on a reply...