Since the 21st june all my post in my web have zero in the G+ button indicator although in Google plus all of them has many +1. For example:
Google plus post +6:
https://plus.google.com/u/0/111402624595533102497/posts/3tQoKE2juv4
Post in my web +0:
http://iphone-6.es/iphone-5s-lanzamiento-20-septiembre-espana/
But the home page gets right the +1
I have investigated what I have done and I think the issue is:
In june I activated Cloud Flare (I had to change my DNS) and the 19th of june I switched off cloud flare and my internet provider gave me another DNS (differents to the ones I had before all this change)
** Nowadays, the domain is in an internet provider and the hosting in a different one. I give this information in case it can be useful.
It might be possible that the URL picked up by the Google+ proxies is different as a result of the changes. As far as I can tell, everything is set correctly, but if there was a URL from before that was different, you can try providing the URL explicitly in your button markup:
<a
rel="nofollow"
class="addthis_button_google_plusone"
g:plusone:size="medium"
href = "http://iphone-6.es/iphone-5s-lanzamiento-20-septiembre-espana/"
onclick="_gaq.push(['_trackEvent', 'finpost', 'click', 'google-plus-sidebar', 0 ,true]);">
</a>
I tried this with your example URL and it doesn't seem to be making a difference. You might also want to check that your canonical tags have not changed because this could prevent the proxy from mapping your site back to the original link.
Upon further inspection it looks like your +1 links might not be resolving correctly. For example, this page seems to be working. You might want to try the following:
Explicitly setting the urls (as shown above) to what the pages were resolving as before.
Removing the canonical tag from your page to see if it resolves better.
Identifying articles where the +1 is working and comparing where it doesn't - there is probably a pattern for the pages not matching.
Related
I'm currently in the process of writing a REST API and this question always seems to popup.
I've always just added a description, quick links to docs, server time etc, but see now (after looking around a bit) that a simple redirect to the API docs would be even better.
My question is what would be the accepted norm to have as the root - '/' - "homepage" of your API?
I've been looking at a few implementations:
Facebook: Just gives a error of "Unsupported get request.";
Twitter: Shows an actual 404 page;
StackOverflow: Redirect to quick "usage" page.
After looking at those it's clear everyone is doing it differently.
In the bigger picture this is of little significance but would be interesting to see what the "RESTfull" way of doing it (if there is one) might be.
Others have had the same question and as you discovered yourself everyone is doing it their own way. There is a move in this direction to somehow standardize it, so see if you find this draft useful:
Home Documents for HTTP APIs aka JSON Home.
I've give this much thought and right now I either return a 404 page, a health status page, a dummy page or redirect to another page, mostly likely on within the organization.
An API homepage isn't something everyone should be looking at and believe me, it can be found. There are more people like me that love to inspect the browser and see how a website is performing.
I have a page tab app that I am hosting. I have both http and https supported. While I receive a signed_request package as expected, after I decode it does not contain page information. That data is simply missing.
I verified that like schemes are being used (https) among facebook, my hosted site and even the 'go between'-- facebook's static page handler.
Also created a new application with page tab support but got the same results-- simply no page information in the signed_request.
Any other causes people can think of?
I add the app to the page tab using this link:
https://www.facebook.com/dialog/pagetab?app_id=176236832519816&next=https://www.intelligantt.com/Facebook/application.html
Here is the page tab I am using (Note: requires permissions):
https://www.facebook.com/pages/School-Auction-Test-2/154869721351873?id=154869721351873&sk=app_176236832519816
Here is the decoded signed_request I am receiving:
{"algorithm":"HMAC-SHA256","code":!REMOVED!,"issued_at":1369384264,"user_id":"1218470256"}
5/25 Update - I thought maybe the canvas app urls didn't match the page tab urls so I spent several hours going through scenarios where they both had a trailing slash or not. Where they both had a trailing ? or not, with query parameters or not.
I also tried changing the 'next' value when creating the page tab to the canvas app url and the page tab url.
No success on either count.
I did read where because I'm seeing the 'code' value in the signed_request it means Facebook either couldn't match my urls or that I'm capturing the second request. However, I given all the URL permutations I went through I believe the urls match. I also subscribed to the 'auth.authResponseChange' which should give me the very first authResponse that should contain the signed_request with page.id in it (but doesn't).
If I had any reputation, I'd add a bounty to this.
Thanks.
I've just spent ~5 hours on this exact same problem and posted a prior answer that was incorrect. Here's the deal:
As you pointed out, signed_request appears to be missing the page data if your tab is implemented in pure javascript as a static html page (with *.htm extension).
I repeated the exact same test, on the exact same page, but wrapped my html page (including js) within a Perl script (with *.cgi extension)... and voila, signed_request has the page info.
Although confusing (and should be better documented as a design choice by Facebook), this may make some sense because it would be impossible to validate the signed_request wholly within Javascript without placing your secretkey within the scope (and therefore revealing it to a potential hacker).
It would be much easier with the PHP SDK, but if you just want to use JavaScript, maybe this will help:
Facebook Registration - Reading the data/signed request with Javascript
Also, you may want to check out this: https://github.com/diulama/js-facebook-signed-request
simply you can't get the full params with the javascript signed_request, use the php sdk to get the full signed_request . and record the values you need into javascript variabls ...
with the php sdk after instanciation ... use the facebook object as following.
$signed_request = $facebook->getSignedRequest();
var_dump($signed_request) ;
this is just to debug but u'll see that the printed array will contain many values that u won't get with js sdk for security reasons.
hope that helped better anyone who would need it, cz it seems this issue takes at the min 3 hours for everyone who runs into.
I have a Google+ button installed on three different domains which essentially differ only in the TLD part (example.de, example.at, example.ch). It might also be worth noting that the websites themselves are almost identical which means that for every page on one of the websites there is an identical one on other two domains (don't ask me why it was a request made by the agency responsible for SEO).
The problem is whenever I use a +1 button on, lets say, example.de homepage it's count number also increases on two other domains although in my +1 profile only the clicked page is displayed. Now if I go to the example.at homepage and click the +1 button to remove my +1 it will also be removed from the +1 count number on all the other websites.
As for the technical part of the question I am using the standard non-asynchronous version of the +1 button meaning my code essentially looks like this.
<!-- Some code... -->
<div class="g-plusone"></div>
<!-- ... even more code... -->
<script type="text/javascript" src="https://apis.google.com/js/plusone.js">{lang: 'de'}</script>
Additionally I don't explicitly set the href part for the +1 button on every page but rather let the Google Plus script figure it out by itself. I know its not the recommended approach (its even stated in the Google Plus documentation) however this approach used to work very well from the very beginning and I would like to know what might be the potential reason for it to break suddenly.
Honestly I am clueless. I went through all the available documentation on Google+ with no luck and its almost impossible to find anything about this problem on the web.
Any help would be greatly appreciated.
You don't mention the actual URL or if you have any other metadata set for the pages in question, but one possibility is that the canonical link is set to the same value for all of the pages in question. In this case, Google treats them all as the same for +1 purposes. See https://developers.google.com/+/web/+1button/#target-url for further details.
I have a website and in my website I have, for example, a list of Audi models. I saw, using google webmaster tools, that my website appears in the google search by the word audi, but the target page was the 22nd page from my result set, not the first. I need my first page to appead, not my last (or middle), but I cannot tell google that this is a parameter, because my URLs are rewritten using mod rewrite. Any ideas?
BTW, I have read in a SEO forum, that it's a bad idea to use a cannonical tag. So is it really a bad idea in my case?
You can't force Google to do anything, however, they have made it easier to deal with pagination issues with a recent post on rel="next" and rel="prev".
But the primary problem you face is signalling to Google that your first (main) page is the starting point - this is achieved using internal link and back-link "juice" focussed on that page. You need to ensure that the first page of results is linked to properly from higher-value pages (like the home-page).
Google recently announced that you can use View All which will allow them to find and index entire articles that are normally broken up using pagination and display them all as one result.
Some e-Marketing tools claim to choose which web page to display based on where you were before. That is, if you've been browsing truck sites and then go to Ford.com, your first page would be of the Ford Explorer.
I know you can get the immediate preceding page with HTTP_REFERRER, but how do you know where they were 6 sites ago?
Javascript this should get you started: http://www.dicabrio.com/javascript/steal-history.php
There are more nefarius means to: http://ha.ckers.org/blog/20070228/steal-browser-history-without-javascript/
Edit:I wanted to add that although this works it is a sleazy marketing teqnique and an invasion of privacy.
Unrelated but relevant, if you only want to look one page back and you can't get to the headers of a page, then document.referrer gives you the place a visitor came from.
You can't access the values for the entries in browser history (neither client side nor server side). All you can do is to send the browser back or forward a number of steps. The entries of the history are otherwise hidden from programmatic access.
Also note that HTTP_REFERER won't be there if the user typed the address in the URL bar instead of following a link to your page.
The browser history can't be directly accessed, but you can compare a list of sites with the user's history. This can be done because the browser attributes a different CSS style to a link that hasn't been visited and one that has.
Using this style difference you can change the content of you pages using pure CSS, but in general javascript is used. There is a good article here about using this trick to improve the user experience by displaying only the RSS aggregator or social bookmarking links that the user actually uses: http://www.niallkennedy.com/blog/2008/02/browser-history-sniff.html