I’m trying to troubleshoot a specific behavior. The last entry I wrote on a WordPress blog returns no data when run through Facebook’s Object Debugger (linter). I just get a “Error Parsing URL:Error parsing input URL, no data was scraped.”
However, if I try with any previous post, all seems to be fine: the linter scrape the page correctly;
If the Facebook button under the problematic entry is clicked, a snippet is correctly produced, except for a thumbnail of the image: permalink, summary, all is correct.
When I examined the source code of for the permalink entry in my browser, I can see all tags correctly displayed, even the og:image tag (the URL is valid).
This is sudden behavior. I didn’t experience any problem since I setup Facebook Open Graph protocol on my blog.
P.
Got it. Sometime between the time I created my previous entry and the time I wrote the new one, the CDN (content delivery network) I’m running me blog through stopped working.
Facebook linter wasn’t happy because it couldn’t find the image (since the image wasn’t distributed through the CDN: the CDN handles media, not plain text, that’s why Facebook was still able to scrape title, summary, etc.).
Lesson learned: when running test with Facebook Object Debugger, first disable any cache system (or make sure it works properly) or it may impact the results.
Related
according to this page (https://developers.facebook.com/docs/instant-articles/analytics) on the Facebook Instant Articles documentation is possible to debug them in a browser using the following url:
www.ia-tracker.fbsbx.com/instant_article_test?url=<share-url>
Now I keep getting the following error:
Notice The trackers are run in same environment as Instant Articles,
except that the base url is different. On Instant article, it's the
url, that the user shared.
I tried to use the canonical url, without http, with www but nothing worked.
Have someone been able to use this method successfully, and if yes what they mean by "share url"?
The debug page doesn't actually render your page in the browser, it running the tracking code it finds just like they would be run in the instant article renderer. If you open the source code of the page you will see that there is a tracker code loaded.
The purpose of that page is to test analytics code, not the FIA itself.
Basically you will have the error if you put wrong URL or if you put the URL to the article that doesn't have FIA implemented. That notice that you get is sign of successfully loaded analytics code from the FIA itself.
Some Time ago our users reported problems with sharing content from our page (text/image wouldn't show up in the share dialog), after some research we added the og:image:width and og:image:height-tags. To reduce loading time, the facebook-scraper receives the page with an empty <body> (we had troubles with timeout too).
Everything worked great until about a week ago. Pages that have already been scraped showed errors in the Object-Debugger:
Error parsing input URL, no data was cached, or no data was scraped.
This error shows up nearly everytime i click Show existing scrape information, eventually it would go away (without re-scraping the page) but then following error shows up:
The 'og:type' property is required, but not present.
The Sharing-Debugger additionally shows following error:
The parser's result for this metadata did not match the input metadata. Likely, this was
caused by the data being ordered in an unexpected way, multiple values being given for a
property only expecting a single value, or property values for a given property being
mismatched. Here are the input properties that were not seen in the parsed result:
'fb:admins, og:type, og:description, og:title, og:site_name, og:image:url, og:image:width,
og:image:height'
Sometimes it also says that our images are too big and couldnt be downloaded, but the image is shown in the preview. Sometimes it even goes as far as showing
Could not scrape URL because it has been blocked
What doesnt add up here is that if i click on See exactly what our scraper sees for your URL it shows me the source of our page with empty <body> and <og:...>-tags in the <head>
The debugger shows me the correct og:url, og:type, og:title, og:description and og:image, the preview is alright, response code is 206 and last scraping was somewhere in August.
After rescraping a few times, most of the time the error messages are gone, but that cant be the solution. It seems as if the debugger sends random errors for whatever reason
So what do these error messages really mean? Are they wrong? What am i missing here?
(Note: a 3rd pary is having trouble sharing our pages in their application due to those error messages, everytime they appeared in the debugger, their data seems to be somehow broken)
After some back and forth with one of facebooks supporter in the developer forum, they acknowledged my problem as a bug and assigned a team for further investigation. However, a few days later my bug report was closed with following message:
Those messages are due to a bug in our Debugger when you scrape no-canonical URLs. On that case, the information about your URL is updated asynchronously so it takes a little while for the error messages to go away.
If you input the canonical URL in the debugger, the error messages will go away after the first scrape.
Unfortunately, due to the way our systems works, we are not planning to fix that error in the near future.
The problem i have is that i own a website where other people can post stuff ,creating new pages on my domain, but the problem that occured today is that all the new post pages created today are malfunctioning , sharing is not loading thumbnail picture and title and so on, but the weird this is that all the posts(new pages) created before today are all working fine
What caused an error to occur out of nowhere?
I also cannot debug any of the URL's of my website as the same error: Error parsing input URL, no data was scraped
The website im having problems with is here http://www.vabameedia.ee/vm/184/h%C3%A4da-ei-anna-h%C3%A4beneda.html
This is one of the sites where it says no error on page but facebook still cant reach it. http://www.vabameedia.ee/vm/178/craig-parks-%C3%BChek%C3%A4eline-krossisoitja.html
For people experiencing the same problem but for different causes, I discovered a few interesting things about how Facebook "scrapes" pages, checking the logs of the server while doing some trials.
First of all: if you never tried to share a page with FB, FB never tried to scrape it, and it will not try to do so if you only put the url in the Debug tool.
That's the first reason because you get the error: it just states that FB has no information on the page, you must "force" it to scrape the page.
The first time you try to share a page, FB scrapes it (asks your server the first 40k of the page and analyse the opengraph tags).
What can happen is that you do not see the image: Facebook Share Dialog does not display thumbnails one first load
The reason is that FB behind the scenes is still scraping your page and caching the image. The next time, in fact, you have also the image.
How to solve it? Pre caching: https://developers.facebook.com/docs/sharing/best-practices#precaching
or simply add
<meta property="og:image:width" content="450"/>
<meta property="og:image:height" content="298"/>
I was pulling my hair out trying to fix this issue. Hours and hours of troubleshooting to no avail. After speaking with one of our programmers about a topic unrelated I thought of something to try as a long shot.
Much to my surprise, it worked!!!
This is the reason behind the problem and my solution for it:
When you draft a post in WordPress it generates a link based on your article's title (unless you manually change it). The title of my article included special characters, however the auto-generated link didn't display these special characters, only hyphens to replace the spaces. Should be fine right? Wrong! Somewhere embedded in metadata and code in the WordPress platform are those special characters and they mess up the way Facebook pulls info from the article being linked to. This is a problem because certain special characters invalidate hyperlinks.
For example:
Article Title: R[eloaded]
Auto-generated hyperlink DISPLAYED in WordPress "Permalink" field: http://www.example.com/reloaded
Actual WordPress Auto-generated hyperlink: http://www.example.com/r[eloaded]
Those brackets will invalidate the link and Facebook will be unable to pull any information (ie pictures) from it.
Solution:
(1) Simply, manually change the WordPress hyperlink address to something that doesn't include any special characters (this will not change the title of your article).
(2) Click "Update" to change the post to include the new hyperlink.
(3) Click "Purge from Cache" in the WordPress window
(4) Refresh your Facebook browser window
(5) Paste the new hyperlink for your article
(6) Enjoy your Facebook post with a preview image and information
Sidenote: Don't pull your hair out over Facebook, it's not worth it. =)
If you're using Wordpress, edit the post in question to change the permalink (just alter it slightly), then update the post. Using the new permalink in the Facebook OG debugger should now work.
It's a weird fix, but I think it takes care of a problem caused by special characters being used in the title of a post, which is then used to make the permalink.
Its all about DNS issue, was having same issue and resolved it by updating domain name servers to actual name servers.
In my case my domain was pointed to ns1.websterz.net and ns2.websterz.net and on this server i had DNS redirect to my other server (where web site is hosted). I Just updated name servers of the domain to actual name servers where my web site is hosted on. This was account migration case i forgot to update name servers as of new server.
Everything works fine now.
We are developing an app that makes posts on behalf of our users to Facebook. Within those posts, we want to put links to external (non-Facebook) websites.
Looking at the links in the status bar of the browser (usually Chrome), the correct URL is displayed. However, Facebook seems to wrap the actually-clicked link into some extra bells-and-whistles. Usually, this works correctly.
Sometimes, however, this URL wrapping ends up sending the click to a URL like:
http: //spywaresite.info/0/go.php?sid=2
(added space to make it non-browsable!) which generates Chromes severe warning message:
This happens very occasionally on Chrome, but very much more often in the iOS browser on the iPhone.
Does anyone have any pointers as to how to deal with this?
EDIT
For example, the URLs we put in the link is
http://www.example.com/some/full/path/somewhere
but the URL that actually gets clicked is:
http://platform.ak.fbcdn.net/www/app_full_proxy.php?app=374274329267054&v=1&size=z&cksum=fc1c17ed464a92bc53caae79e5413481&src=http%3A%2F%2Fwww.example.com%2Fsome%2Ffull%2Fpath%2Fsomewhere
There seems to be some JavaScript goodness in the page that unscrambles that and usually redirects correctly.
EDIT2
The links above are put on the image and the blue text to the right of the image in the screenshot below.
Mousing over the links (or the image) in the browser shows the correct link. Right-clicking on the link and selecting "Copy Link Address" gets the fbcdn.net link above (or one like it). Actually clicking on the link seems to set off some JavaScript processing of the fbcdn.net link into the right one... but sometimes that processing fails.
I'm not 100% sure what you're asking here, but i'll tell you what I know:- are you referring to this screen on Facebook?
(or rather, the variation of that screen which doesn't allow clickthrough?)
If you manually send a user to facebook.com/l.php?u=something they'll always see that message - it's a measure to prevent an open redirector
if your users are submitting such links, including the l.php link, you'll need to extract the destination URL (in the 'u' parameter)
If you're seeing the l.php URLs come back from the API this is probably a bug.
If links clicked on facebook.com end up on the screen it's because facebook have detected the link as suspicious (e.g. for URL redirector sites - the screen will allow clickthrough but warn the user first) or malicious/spammy (will not allow clickthrough)
In your app you won't be able to post links to the latter (an error will come back saying the URL is blocked), and the former may throw a captcha sometimes (if you're using the Feed dialog, this should be transparent to the app code, the user will enter the captcha and the dialog will return as normal)
If this isn't exactly what you were asking about please clarify and i'll update my answer
Rather than add to the question, I thought I'd put more details here.
It looks like the Facebook mention in the original title was mis-directed, so I've removed it.
We still haven't got to the bottom of the issue.
However, we used both Wireshark and Fiddler to look at the HTTP traffic between the Chrome browser (on the PC) and Facebook. Both showed that Facebook was returning the correct URL refresh.
Here's what Wireshark showed:
What we saw on Fiddler was that our server is issuing a redirect to the spywaresite.info site:
We are working with our ISP to figure out what is happening here.
I've updated my site with OG meta information, but it's not working perfectly. On this portal some article is unreachable for Facebook (Comments say about it). But when I paste URL in FB status, it can't load initial image and teaser for this article. This problem is not permanent, but too often to make me sad. Clicking on the link takes me to the developers.facebook.com/tools/lint? page, and can't say any error, everything seems to be fine. What can I do, can anybody help me?
Some URLs for checking (clicking on the debug page the error message disappear, and everything will be fine):
http://www.femcafe.hu/cikkek/celeb/jessica-simpson-2-millio-dollaros-szulese
http://www.femcafe.hu/cikkek/celeb/nem-haragszom-markra-interju-eden-kiraval
If you need more URLs, I can send more.
The new link for lint is :
http://developers.facebook.com/tools/debug
Make sure you don't have any redirects on your pages/links, it will scrape the last/final url.
Check if you have any cache issues etc.
I don't see any errors