Redirecting to page ID if "rel=canonical" setup to pretty URL

Redirecting to page ID if "rel=canonical" setup to pretty URL - If a page has internal and external outgoing links to redirecting URLs, it’s returning 3xx (301, 302, etc.) HTTP status codes standing for redirection. This issue means that the page does not exist on a permanent or temporary basis. It appears on most of the popular web browsers, usually caused by a misconfigured website. However, there are some steps you can take to ensure the issue isn’t on your side. You can find more details about redirecting URLs by reading the Google Search Central overview. In this article, we’ll go over how you can fix the Redirecting to page ID if "rel=canonical" setup to pretty URL error on your web browser. Problem :

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.

Solution :

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?

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.

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.

We hope that this article has helped you resolve the redirects, canonical-url, error in your web browsers. Enjoy browsing the internet uninterrupted!