: Redirecting to page ID if "rel=canonical" setup to pretty URL When changing the URL structure for a site with 10,000's of pages is it acceptable to redirect to a page id (eg example.com/1234)
When changing the URL structure for a site with 10,000's of pages is it acceptable to redirect to a page id (eg example.com/1234) if a "pretty" URL has been set in the rel=canonical tag?
For example:
An old URL example.com/news/truncated-headline-goes-here/1234 redirects to example.com/5678. And the canonical example.com/news/year/month/day/full-headline-goes-here.
More posts by @Odierno851
3 Comments
Sorted by latest first Latest Oldest Best
Here is how I would pull that off:
First, make sure on import that your node/content ID's start at a number HIGHER THAN your old ID's. You should make 2 new columns in the DB of your new platform. Call the columns something like "old_node_id" and "old_seo_url". Prepare an import using the schema/mapping of your new platform, with the addition of those 2 extra "old columns" from the old content. Make sure only the old content has data in those cols. You can use "0" for the old_node_id if it doesn't and you can just leave the old_seo_url col blank if none set. Now you will have a functional listing of content with the addition of 2 trigger columns that will be used to deduce whether an A) node ID and/or B) seo url rewrite is needed.
Next, depending on what platform/language/structure you are using, you need to deduce where to drop a router script. Sometimes this is in a header controller. Sometimes this is in a seo/url/request/response class. Sometimes this is simply in the index file. Or sometimes its nowhere useful and 404 is the best.
Unfortunately, it seems that your old platform (WP?) doesnt use querystring to identify ID's, but that's ok. What the script needs to do is first look for the combination of existence of old_node_id and part of the seo url in the new URi. You can use $_SERVER constants (or whatever lng/codebase needs) to do this lookup within the URi string. If it matches anything in those 2 new columns you added, forward the request there.
BTW: If you get mega traffic, you should def autocache these maps as they are found, use a huge TTL so they dont need to regen.
As Sandeep has already stated, it's not ideal to redirect to the non-canonical URL when this is intended to be a canonical redirect. You are sending mixed messages to the search engines.
old url: example.com/news/truncated-headline-goes-here/1234
redirects to: example.com/5678
There is the nagging thought... If you are able to determine that you need to redirect to /5678 (which seems to be unrelated to the old URL and not something that could be determined in .htaccess / server config alone) then why are you not able to determine the new canonical URL?
otherwise the redirects file will be 10,000's lines long
You wouldn't necessarily do this type of redirect in .htaccess (or server config), if that is what you are implying. Create a custom 404 document that is able to lookup the correct canonical URL from your new CMS and then redirect to that canonical URL.
This way the processing (a single DB lookup) only occurs when the old URL is not found and not by trawling through a mass of redirects on every request.
No, this isn't the right way to to it.
Why don't you use "Pretty URL" as your targeted URL and redirect/put canonical on the old url?
Terms of Use Create Support ticket Your support tickets Stock Market News! © vmapp.org2024 All Rights reserved.