I have a ecommerce site with hundreds of products. I recently changed permalinks and their base. Using Wordpress and Woocommerce plugin, I removed /shop/%product-category% from the URL. However, my old URLs are still active. Check out the following example:
greenenvysupply.com/shop/accessories/gro1-1-3mp-usb-led-digital-microscope-10x-300x/
greenenvysupply.com/gro1-1-3mp-usb-led-digital-microscope-10x-300x/
The first URL is old. Why does it still work? Shouldn't I get a 404 page?
Here is code from page source related to the canonical:
href="https://www.greenenvysupply.com/shop/feed/" />
<link rel='canonical' href='https://www.greenenvysupply.com/gro1-1-3mp-usb-led-digital-microscope-10x-300x/' />
<meta name="description" content="The 1.3 Mega-Pixel USB LED Digital Microscope is great for identifying pests and diseases on your plants so you can accurately resolve the problem."/>
<link rel="canonical" href="https://www.greenenvysupply.com/gro1-1-3mp-usb-led-digital-microscope-10x-300x/" />
Because the old URL is still active and not redirecting, my entire website is being seen as having duplicate content. Google crawlers are not being redirected. Why is the URL with /shop/ in it still active even though I have changed the permalink? There has got to be an easy fix for this.
A canonical URL or other metadata in your response is not the same as a redirect. To accomplish a redirect, your server needs to return a 3xx status code (typically a 301 or 308 for a permanent move as you have here or a 302 or 307 for a temporary move) and return a "Location" header that indicates the URL to which to redirect. How exactly you make your server do this is dependent on the type of server or server framework that you happen to be using for your website.
How to accomplish a redirect is somewhat independent of your implicit SEO question about whether to prefer a redirect over a canonical URL, which I'm afraid I cannot answer. Regardless of the approach you use, though, you should be aware that search engines -- Google or otherwise -- may not reflect the changes from your website immediately, so don't panic if you don't see the desired search engine change you were looking for immediately following a change to your website.
Related
I have added 301 redirect on my website by mistake (because I was doing maintenance). Now lots of people can't get back to my website, because they are still redirected to other page - eventhough I removed redirection (even deleted htaccess). As much as I searched around it's because htaccess (or 301 redirect) is cached in users browser and I wasn't able to find any solution for this. Is there any way to fix this, I can't just loose hundreds of visitors because of something like this?
This page explains what is going on in good detail:
301 Redirects: The Horror That Cannot Be Uncached
Basically, modern browsers cache the redirect response for 301 for some indeterminate amount of time and will not make an updated request to your old web page to refresh it. Users can manually clear the cache and, because it is a cache, data can be purged if the browser needs more space for other data (like other redirects).
This SuperUser question resolves the caching issue from the client's end:
How can I make Chrome stop caching redirects?
One interesting answer is:
//superuser.com/a/660522/178910
In this answer, the user points out that the browser treats http://example.com/ and http://example.com/? as two different URLs. You could go to the "new" site and setup an HTTP 302 redirect pointing back to the original page with a ? on the end and it should load. If they original page already had a query as part of the URL, you can simple add an & to the end to achieve the same result.
It's not perfect -- it is a different URL after all -- but at least they'll be able to view your old site.
Note that your web application may try to redirect empty queries or invalid queries back to a "clean" page, which you may have to disable to get the intended result.
UPDATE
One other option is to put a redirect from the new site back to the old site (make this a 302 or 307 redirect to avoid the 301 problem you're currently having). From my testing, Chrome will remove the old redirect when it does this. It may throw a "redirect loop" error, but only once. I was unable to reproduce the cached redirect problem at all with the latest version of Firefox. Other browsers' behavior is probably going to be inconsistent.
I am new to this so I will try to explain myself clearly.
I am doing my 301 redirect from a custom 404 page. Now I got it working my question is more regarding how google would treat this. Cause we going to a 404 page would google just record it as a 40 page or would it actually record the 301? As i said I am new to this and have looked through google to try and find an answer to this.
Anyway any help or comment would be greatly appriciated. thanks in advance
Best practice in this case could be:
If the page doesn't exist, but we have new one, with highly similar content, we can make 301 redirection, simply saying: "Moved permanently", which is instructing Google to actually take new URL on account and prioritize it.
If the page doesn't exist, and we actually have no idea why someone could type this link, as this URL never existed and is just wrong, then we serve 404 "Not Found". It simply means that the URL is wrong, and someone (or some other website) has fooled you to follow this link. You shouldn't automatically redirect user from this page, but place a link to the homepage instead, so user can choose his action.
If the page doesn't exist, and we know that we had this page, but it doesn't exist, and it will not exist in the future as well (we has simply decided that we will no longer have this page), then serve 410 "Gone" page, with a link to homepage as well, and let user decide.
HTTP codes, are not just a theory, it's a standard we should use. I noticed, that many 404 pages are served without correct HTTP response code, which only suggests that there is a poor development behind it.
More about HTTP response codes here: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
From my understanding, a 301 redirect is the best way to retain "link juice" and should be used if the 404 page is referencing has a lot of external links, has substantial traffic, etc.
Sending a generic 404 page straight to the home page is not ideal, as it may confuse the user. Allowing the 404 keeps the page from being repeatedly indexed and crawled by search engines.
Read more about it here: http://moz.com/learn/seo/http-status-codes.
it is not ok to redirect 404 page to another. it's better to correct it and show the old page. if it's impossible you should show 404 page and put some helpful links in it.
if you want to redirect to the correct one it's ok but the best way is to show display original page regardless of duplication. but you must use rel canonical to tell search engines where is the correct version on the page.
https://support.google.com/webmasters/answer/139394?hl=en
I have implemented SEO URLs using Apache 301 redirects to a 'redirect.cfm' in the root of the website which handles all URL building and content delivering.
Post data is lost during a 301 redirect.
Unable to find a solution so far, have tried excluding post method from rewrites - worst case scenario we could use the old type URLs for post methods.
Is there something that can be done?
Thanks
Using a 307 should be exactly what you want
307 Temporary Redirect (since HTTP/1.1)
In this case, the request should be repeated with another URI; however, future requests
should still use the original URI.[2] In contrast to how 302 was historically implemented,
the request method is not allowed to be changed when reissuing the original request. For
instance, a POST request should be repeated using another POST request
- Wikipedia
Update circa 2021
The original answer here was written before 307 status code redirect worked consistently across browsers. As per Hashbrown's answer below, the 307 status code should be used.
Old Answer
POST data is discarded on redirect as a client will perform a GET request to the URL specified by the 301. Period.
The only option is to convert the POST parameters to GET parameters and tack them onto the end of the URL you're redirecting to. This cannot be done in a .htaccess file rewrite.
One option is to catch POST requests to the url to be redirected and pass it off to a page to handle the redirect. You'd need to do the transposition of the parameters in code then issue the redirect header with the parameter appended new url that way.
Update: As pointed out in the comments to this answer, if you do redirect to another URL specifying POST parameters and that URL is also accessed without paramters (or the params are variable), you should specify a link to the canonical URL for the page.
Say the POST form redirects transposed to the following GET resource:
http://www.example.com/finalpage.php?form_data_1=123&form_data_2=666
You would add this link record to the head section of the page:
<link rel="canonical" href="http://www.example.com/finalpage.php" />
This would ensure all SEO value would be given to http://www.example.com/finalpage.php and avoid possible issues with duplicate content.
Using 301 redirects for general URL rewriting is not the way to go.
This is a performance issue (especially for mobile, but also in general), since it doubles the number of requests for your page.
Think about using a URL rewriting tool like Tuckey's URLrewriteFilter or apache mod_rewrite.
What Ray said is all true, this is just an additional comment on your general approach.
Ok, i used the below to "seoize" my urls. It works great..the only problem is when i go to the old page it doesnt redirect to the new page.. so i have a feeling i will get two pages indexed in google... how can i just permenantly redirect the old pages eto new urls...
RewriteRule ^city/([^/]+)/([^/]+) /rate-page.php?state=$1&city=$2 [NC]
http: / / www.ratemycommunity.com/city/Kansas/Independence
and old page = http://www.ratemycommunity.com/rate-page.php?state=Kansas&city=Independence
The problem is that the ugly url must be visible, as you need them for the rewrite. Just don't make any links to the ugly urls.
If search engines already know about the ugly urls, you can add another query parameter, say show=yes.
In the rewrite rule, ensure that you have the last parameter show=yes. If not, redirect to the nice url, which in turn will rewrite to the ugly url with the last parameter. Then, never link externally to the ugly url with the show=yes parameter.
Example:
/rate-page.php?state=Somestate&city=Somecity&show=yes
Accessing this page will show the content, but you must not make that link visible from anywhere.
/city/Somestate/Somecity
should be rewritten to /rate-page.php?state=Somestate&city=Somecity&show=yes, and
/rate-page.php?state=Somestate&city=Somecity
should be redirected to /city/Somestate/Somecity
The best thing to do is use cannonicalization, a recently introduced page tagging concept that tells Google and other crawlers what you want to be the URL of record. Check out this documentation and video by Google SEO guru Matt Cutts.
In your case, it will look like this:
<link rel="canonical" href="http://www.ratemycommunity.com/city/Kansas/Independence"/>
I am getting the security alert: "You are about to be directed to a connection that is not secure. the information you are sending to the current site might be transmitted to a non-secure site. Do you wish to continue?" when I try to login as a customer on my clients oscommerce website. I noticed the link in the status bar goes from a https prefix to a nonsecure http prefix. The site has a SSL certificate, so how do I ensure the entire store portion of the site directs to the secured site?
It is likely that some parts of the page, most often images or scripts, are loaded non-secure. You'll need to go through them in the browser's "view page source" view one by one and eliminate the reason (most often, a configuration setting pointing to http://).
Some external tools like Google Analytics that you may be embedding on your site can be included through https://, some don't. In that case, you may have to remove those tools from your secure site.
If you can't switch all the settings, try using relative paths
<img src="/images/shop/xyz.gif">
but the first thing is to identify the non-secure elements using the source code view of your browser.
An immediate redirection from a https:// page to a http:/ one would not result in a warning as you describe. Can you specify what's up with that?
Use Fiddler and browse your site, in the listing it should become evident what is using HTTP and HTTPS.
Ensure that the following are included over https:
css files
js files
embedded media (images, videos)
If you're confident none of your own stuff is included over http, check things like tracking pixels and other third-party gadgets.
Edit: Now that you've linked your page, I see that your <base> tag is the problem:
<base href="http://balancedecosolutions.com/products//catalog/">
Change to:
<base href="https://balancedecosolutions.com/products//catalog/">
If the suggestion from Pekka doesn't suit your needs you can try using relative links based on the schema (http or https):
e.g.,
I am a 100% valid link!
The only problem with this technique is that it doesn't work with CSS files in all browsers; though it does work within Javascript and inline CSS. (I could be wrong here; anyone want to check?).
e.g., the following :
<link rel="stylesheet" href="/css/mycss.css" />
<!-- mycss.css contents: -->
...
body{
background-image:url(//static.example.com/background.png);
}
...
...might fail.
A simple Find/Replace on your source code could be easy.
It sounds to me like the HTML form you are submitting is hardcoded to post to a non-secure page.