I am currently redirecting a website to another new website. My question is does a redirect automatically move my metadata (titles, taglines, meta description, focus keyphrases) to the new site? or Do I have to manually copy and paste metadata to the new site?
Better put - do my rankings from the old site as a result of metadata automatically point to my new site upon redirecting?
Thanks.
You are going to want to look into using a specific kind of redirect, which is the HTTP 301 redirect. That status code means its a permanent redirect, and most search engines will recognize that and will help keep your SEO.
If you do a HTTP 302 redirect, this being known as a temporary redirect, will technically be considered a new URL in the eyes of a search engine.
So when you are testing you redirect, make sure you open up Chrome Dev Tools (F12) and click the network tab. Refresh the page and click the first row that appears in the table. It should specify the HTTP status code, most likely being 200 (status ok), (301/302) permanent/temporary redirect, (404) file not found, 500 (server error).
So essentially, make sure your redirect is using a 301 redirect, if it is permanent of course!
Related
I'm not sure how to make this question reproducible because it requires having a Vimeo paid (or on a free trial) account.
Vimeo recently changed their UI for creators and made it harder to access one of the pages I use every day.
From https://vimeo.com/manage/videos there is a table with links to individual videos. The URL for each link is something like https://vimeo.com/55555555555555/settings.
If you click, it sends you to Page A: https://vimeo.com/manage/videos/55555555555555.
Then, there's a button that sends you to the page I actually need (Page B): https://vimeo.com/manage/55555555555555/general.
The problem is that when I enter the URL for Page B directly in my browser, it redirects me back to Page A.
Strangely, the back/forward buttons navigate between pages A and B, and the refresh button also stays in Page B. But if I copy Page B's URL, open a new tab and paste it, it sends me back to Page A.
To figure out what's going on, I looked in the network tab of the Chrome Developer tools and found that the first request from Page A to page B looks like this:
But then, if I paste that URL in a different tab, I get a 302:
I've diffed both requests:
Is there a way to prevent the 302 behavior?
I don't have a vimeo account and thus can not test it. Ultimately, the server could use any parts of the diff, but I'd expect it to use the referrer.
Does the page always direct you back if you completely disable setting the referrer in Chrome? If so, using a plugin to forge your referrer could solve the issue.
Unlike 301 redirects which are permanent, 302 are not. The web server displaying 302 errors should redirect the browser and take you to the new location immediately. It should be noted that HTTP 302 status code is due to the web server and not the web browser. There is no control at your end.
I found that anybody show their page to user, then 302 redirect to my site,
I want stop it.
I thought there would be referer in request header, but didn't!
I tested this in chrome72.0.3626.121 and ie11, and use fiddler to catch Request,
there have no referer header in all request.
And my server side code can't see referer too.
How can I stop 302 redirect to my site??
It's possible these days for sites to disable adding a referrer when a user follows a link. This is a privacy feature.
The result of sites using this feature is that you can't tell if:
A) A user opened your site directly from the addressbar
B) A user came to your site from somewhere else.
If you could tell the difference, it means the privacy feature is not working. Your only option is to block anyone with no referrer header, but then you might block a lot of other users as well.
There is one other common reason for this though, if you are running an insecure (http) site and you are being linked from secure (https://) site. It might be possible to get the referrer back in this case by upgrading your site to https.
Is there any way to identify the url which redirected to another one?
To be clear, let's say we have example-domain.com which redirects (302) to exampledomain.com.
I thought that maybe the http_referer server variable would contain the redirecting url but thats not the case. Is that possible at all?
Wouldn't let me comment or upvote as I'm too new. Wondering if you're still having this problem - as I am too.
If you have control over both domain names, I would suggest you 302 to the URL exampledomain.com?refUrl=example-domain.com and pull the data from the querystring.
If you DON'T have control over both domain names, you are in same situation as me and my non-intentional duplicate question (3rd party is 302 redirect to my website, how to stop?)
In my case from testing, the http_referrer returns the site 'before' the site doing the 302. IE "Google (Click) Example-Domain (302) ExampleDomain"... the http referrer returns Google.
I have just migrated a site to a new domain (with new design) and am redirecting from the old site to the new with .htaccess and redirect 301. Since the new site is quite different, I'm concerned that users might be disoriented. Is there a way to have a popup on the new site that users get only if they have been redirected from the old site? Have been searching on this but keywords seem to lead only to stuff on popup redirects to another site.
I can think of several ways to do it:
Redirect in the 301 to another page (www.blah.com/tour instead of www.blah.com) and there i would put the logic to show the popup
Redirect in the 301 to another page and there set a cookie and redirect to the original page. Then, add logic to the original page to show the popup if the cookie is present (and delete the cookie)
Check the referrer in the new site and if it matches the old one, show the popup
Your problem boils down to detecting a request that has come via a 301 redirect - popups and usability are a separate (simpler?!) issue.
Unfortunately, detecting a 301 redirect is one of those inexact things that requires a mixture of techniques to get near to 100%. I say near, but never quite there - a bit like browser detection.
One option is to append a querystring (GET) parameter to the redirected URL, e.g.
www.example.com/LandingPage.html?isRedirected=true
You could also set the same info in a cookie (but won't work if cookies are disabled or cleared).
Another option is checking the Referrer header - but again, these may differ based on browser implementation and can be faked, although if someone's faking a redirect I don't think you need to worry about guiding them through your new design!
We've just put a new website live and I have varying Url re-writing in place to handle the old indexed pages, performing a 301 redirect to the new equivalent page location on the new site.
We've noticed since the day the new site went live that in Google Analytics, the stats in general have plummeted substantially :(
One of our SEO guys has pointed out that when you click on one of the old indexed pages in google, it correctly 301's to the new location, however, if you view the __utmz Google Analytics cookie, it has 'direct' in it, whereas he believes that should be 'organic'.
He thinks that the referrer information is being lost during the 301 redirect, and as a result, this is being treated as direct traffic instead of organic?
The new website is an ASP.NET 4.0 Web Forms application and is using Routing for the new Url's. I am generating the new route/url for old pages within the global.asax within the Application_BeginRequest routine.
If a 301 is needed for the request, this is the code that is executed:
Response.Clear();
Response.Status = "301 Moved Permanently";
Response.AddHeader("Location", newUrl);
Response.End();
Is there anything here that would indicate what the problem might be, or any ideas beyond the above what might be causing such an issue?
I located the problem - a silly error on my part with a relative url to a file that accompanies our google analytics tag, working in some locations of the website, but in others, the include was returning a 404! My bad.