I run a website which seems to have a problem with 303 Redirects.
The CMS is TYPO3 9.5.24.
I don't know where the redirects are coming from. Unfortunately the 303 redirects are not listed in the network tab of the console (testet Chrome, FF). Why not?
The Problem is Facebook is not able to scrape the pages. Their Sharing debugger (https://developers.facebook.com/tools/debug/) tells me "URL requested a HTTP redirect, but it could not be followed."
I checked with https://www.redirect-checker.org/index.php, there I get a loop of 303 redirects.
I can view the website in any browser just fine, no problems there.
I checked .htaccess and the TYPO3 Backend for 303 redirects, but found nothing.
I suspected a server (nginx) misconfiguration but can't figure it out. Other websites on the same server do not have that problem.
Has anyone experienced similar problems?
Found the redirection in our custom code. Had nothing to do with Typo3.
Sorry for the confusion.
Thanks Peter Kraume, the curl check helped me to find the problem.
Appearently modern browsers ignore a 303 redirect loop, so i was not able to see anything in browser console.
Can be closed.
Related
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.
I migrated my site 2 years back (flash based to responsive). But Google crawler still complains that the old files are not reachable. Few times, I marked them fixed in the webmaster tools site. But still producing those errors. Some one mentioned in Google forum, just leave them as errors for a while and crawler marks itself these as obsolete after few attempts. This approach is also not helping. The site is a *nix GoDaddy-site with .htaccess file. Any ideas?
I think it will work if you set up an http re-write rule for your web server, defining the content as http 301, Moved Permanently. Then the crawl bot will start looking in the new place.
So, the bot request:
GET /index.php HTTP/1.1
Host: www.example.org
And the appropriate server response:
HTTP/1.1 301 Moved Permanently
Location: http://www.example.org/index.asp
I've done this with success before, on a forum site where we changed URL format after a year or so.
If the amount of links are not too big, you can redirect each and one of them by doing this in .htaccess:
Redirect 301 /old-page.html http://example.com/new-page.html
Redirect 301 /another-old-page.html http://example.com/another-new-page.html
And it seems that the mod_rewrite is enabled by default, so only type your redirects, and you're home free. When you've had them for a while, they can be taken away again.
I have recently renewed my website, but for some reason the Facebook Open Graph Debugger is not able to re-scrape my new og tags.
When I enter the website, I receive a couple of error messages which makes no sense.
For example:
1.Circular redirect path detected (see 'Redirect Path' section for details).
2. URL requested a HTTP redirect, but it could not be followed.
When I debug my website, and see which HTML status code is given, it is 200 OK. So where does the 301 come from which the Facebook Debugger detects?
What am I missing in my set up?
Thanks in advance.
Redirecting error have happened to me on websites that redirect http to https.
The errors output explains explicitly what is the path the debugger needed to pass. In my case it showed me that it had to pass the following path: https >> http >> https.
This have occurred since the page url i tried to share used https, but in the op meta definition, I have defined it as http. Fixing that resolved all.
Humbly asking for any assistance people have time to give me on this one. Let me start by saying that I am aware there are previous questions about this on this site and elsewhere on the web; I have read a lot of them, and they are either unanswered/resolved, had a particular cause that doesn't apply to me, or suggests things I have already done.
Over the past few days, Facebook has suddenly stopped scraping my website posts successfully, so when I paste a link into Facebook it pulls nothing through - no thumb or description. I run the links through the FB lint/debugger, and it alternates between 403 and 503 response codes, but mainly 403. Previous links that Facebook has cached/successfully scraped still display with thumbs and desc, but still present as a 403 or 503 response.
My site is http://21stcenturyburlesque.com
One of the new URLs I have been testing is : http://21stcenturyburlesque.com/the-burlesque-top-50-2013/
I have checked with the server/host people. Nothing has changed, everything fine.
I have tried with the default wordpress theme. No change.
I have read threads about Bullet Proof Security causing issues, although why it suddenly would I don't know. It was deactivated on my site anyway, but I went through the removal process to remove the htaccess file with the BPS code in it. I have then run debug without an htaccess file present, and with a very basic htaccess present. No change.
Hotlinking protection is disabled in my cpanel.
I have experimented with adding/removing www. and / when I paste the link into lint as someone suggested. No change.
I use Facebook OGP Wordpress plugin. I spoke to the creator and he says the plugin is working as it should and to contact my host/server. See bullet one.
I tried creating a new FB App and using the new App Id number with the OGP plugin. No change.
Checked the cpanel error log. This came up three times tonight:
[Fri Nov 01 21:47:53 2013] [error] [client 193.242.149.35] File does not exist: /home/**/public_html/403.shtml
There are a few other things I ruled out but I've been at this for so long I can't remember all of them, so if someone suggests something else I've tried then I apologise for not mentioning it here in advance.
If anyone can suggest anything else, I would really appreciate it. I manage to fix most technical problems I come up against, but this has stumped me and my much more experienced colleague and it is really affecting my clickthrough rates and site traffic. If it comes down to adding things to my htaccess file, I would appreciate guidance on what to add/remove. Many thanks in advance.
I had the same problem. Drove me crazy for hours (maybe days). In your FB app settings make sure that the top Facebook url has http://
I built a site out of ZF and installed it fine on my server. I have the MVC structure and use custom routing (for SEO purposes) as below:
mysite.com/controller.html
mysite.com/controller/action.html
Generally, everything is working fine but the only problem is that SE crawlers won't find any .html files. If i open the "Activity" window from Safari, I see all the css and other files being referenced/read fine but not the page itself.
So, the page renders fine on a browser but SE crawlers or any program that made the request won't find the page. I'm wondering if it's an Apache issue. My .htaccess file is the same file that shipped with the ZF.
I really appreciate any advise/suggestions/comments!
Is it possible that your app is serving all pages with a 404 status code? So browsers and crawlers are getting the same thing, but the browser will render the content whereas the crawlers ignore it. I've seen some people use the Error Controller in ZF as a way of doing routing (not a good idea), where the Error Controller 'catches' all requests and then examines the params to determine what to display.
If this isn't your problem please could you edit your question to include:
How it is you know that crawlers are getting a 404
Some more info on how you are doing your routing
Also if you can provide an example URL we can check the headers that are being returned.