Google search is making it more difficult to surface iOS applications using typical user queries, like “Whatsapp iTunes,” “Whatsapp iPhone,”  or searches by app name, for example. In the past, this would return a page of search results where the iTunes URL would be ranked highly. Today, those links are further down in Google’s results pages.

In Whatsapp’s case, the iTunes URL doesn’t even appear until close to the bottom of the second page of search results, when logged in while searching for “Whatsapp iTunes,” and it’s at the bottom of page 3 when logged out. It’s even more difficult to find it using “Whatsapp iPhone,” whether logged in or out.

This is but one example, of course.

The search penalty, or search bug if that’s the case, doesn’t seem to affect all apps to the same degree. And the rankings also depend on what search terms are used, and whether the user is signed in.

For instance, while logged in, a search on Google for “Twitter iTunes” returns the iTunes URL in spot #8, below several links to iTunes Twitter accounts. Meanwhile, a search for “Twitter iPhone” returns the iTunes URL in spot #5 (not counting Twitter images results). Previously, the iTunes Twitter URL would rank much higher – often in the top #1 or #2 positions.

But it’s important to note that the above were how apps were ranked while being logged in, meaning signed into a Google account. Because this has long since affected search rankings, we ran the same search as a logged out user. That returns nearly the same in Twitter’s case – #9 (+iTunes) and #5 again (+iPhone).

Still, Twitter’s iTunes URL still appears on page 1 using these queries, which is not bad. However, not all apps are as lucky.

The app search results are very inconsistent. Appending ” iTunes” to the search query often appears to be necessary in order to see the iTunes URL returned to the top spot, which has long been a trick savvy Google users know to use to get the results ranked higher. It’s unclear then, what, if anything, has changed in that regard besides the high-profile examples involving Whatsapp and Twitter above.

Meanwhile, queries for “app + iPhone” are poorly ranked in some cases, while just the app name alone often leads to no iTunes links in top search results, or even top pages.

For comparison’s sake, here are some sample queries, run both while logged in and out of Google. Obviously, if you run the same queries while logged in, your results will differ.

Some of the odder examples are in bold.

“App Name” queries:

• Snapchat: Logged in or Logged out – can’t find iTunes URL after several pages in; while Logged out gave up after page 15
• Flipboard: Logged in – #5 / Logged out – #6
• Tweetbot: Logged in – #6 / Logged out – bottom of page 4!
• Alien Blue (a popular Reddit app): Logged in – not on first 2 pages of results / Logged out - not on first 2 pages of result
• Angry Birds: Logged in – not on first 2 pages of results / Logged out – not on first 2 pages of results

“App + iPhone” queries:

• Snapchat: Logged in – not on first 2 pages of results  / Logged out – near bottom of page 2
• Flipboard: Logged in – #1 / Logged out – #1
• Tweetbot: Logged in – not on first 2 pages of results / Logged out – bottom of page 4
• Alien Blue (a popular Reddit app): Logged in – 2nd link, page 2 / Logged out – 3rd link, page 2
• Angry Birds: Logged in – #1 / Logged out – #1

“App + iTunes” queries:

• Snapchat: Logged in – #1  / Logged out – #1
• Flipboard: Logged in – #1 / Logged out – #1
• Tweetbot: Logged in – #1 / Logged out – #1
• Alien Blue (Reddit): Logged in – #1 / Logged out – #1
• Angry Birds: Logged in – #1 / Logged out – #1

TNW has posted other high-profile examples here, but it’s unclear from the screenshots whether those searches were performed while logged in or out. (Update: spoke to the post’s author, and he confirms they were performed while logged out). 

For most apps, adding “iTunes” works to deliver the iTunes URL results, whether logged in or out. It’s the other types of queries that are difficult, and it’s difficult to pinpoint an exact time when these changes began. Because Google is constantly refining its algorithms, and many users are on Google while logged in, tweaks to search rankings are rarely spotted immediately, unless it’s a case where a URL has been banned entirely, whether or purpose or by accident. (As was the case with Digg, recently).

However, AppsFire co-founder Ouriel Ohayon says while he only first noticed the issue today, he tells us that he was doing some app research on Google two weeks ago, and the rankings were quite different then. Hillel Fuld of Inneractive confirms he’s noticed the same issue for a few weeks now, with fewer and fewer apps appearing in top results, making it more difficult to find the apps he’s searching for using typical queries.

Ohayon says that the changes do matter. “There are still a substantial number of users who use Google for all kinds of search, including their apps,” he says. “It would affect the way people discover apps.”

We’ve reached out to Google for clarification on this, and will update if it offers comment. Currently it’s too soon to call this out as either a new or significant iTunes penalty, despite some odd results and the comments from app industry pros. Reach out if you have more to add.

Article courtesy of TechCrunch

Facebook has quietly released a new feature in Facebook for iPhone 4.0 update that could create new opportunities for marketers. If users click or enter a URL that uses the fb://page URL scheme and have the official Facebook for iPhone/iPad app installed, the corresponding Facebook Page will be opened in that app. Before the 4.0 and later software updates, fb://page URL scheme links would load a blank screen in the apps.

For example, if you click the link of or enter the URL fb://page/7844589738 in an iOS device that has Facebook for iPhone/iPad installed, that app will launch and bring up t he official Facebook Page for InsideFacebook.com (7844589738 is the Facebook ID of the Page for Inside Facebook). Marketers could distribute URL scheme-linked text via email or mobile site, and users wouldn’t notice the strange URL, they’d just click on a link and suddenly see the Facebook app open.

This new functionality could let marketers instantly bring users to their Page where they can Like it or write on its wall, rather than forcing them to open the m.facebook.com site where they might not already be logged in. Marketers could attach this link to a QR code to promote their Page and gain Likes from iOS device users. The fb://page URL scheme could become even more important if users gain the ability to access Page tab applications from mobile devices in the future.

An interesting story today from Nieman Journalism Lab, pointing to the dangers of URL spoofing.

The danger, according to Neiman’s Andrew Phelps, stems from the fact that many news organizations include the text of headlines in their URLs in order to improve SEO. In many cases, the headline text is superfluous, and the URL works just fine without it. The result? A story from the UK’s Independent newspaper that started out with this URL…

http://www.independent.co.uk/life-style/food-and-drink/kate-middleton-jelly-bean-2269573.html

…went viral, after a prankster tweeted it out as…

http://www.independent.co.uk/life-style/food-and-drink/utter-PR-fiction-but-people-love-this-shit-so-fuck-it-lets-just-print-it-2269573.html

(Both URLs work just fine.)

Embarrassingly, and amusingly, several news organizations including Slate and Nieman itself, fell foul of the prank, assuming that it reflected an error at the Independent. Finally realizing his mistake, Phelps wrote his follow-up story, describing “How URL spoofing can put libelous words into news orgs’ mouths”

Well, yes. And no.

For a start, the problem isn’t a new one. I remember, almost ten years ago, laughing my ass off when my friend Tim Ireland noticed that the website of British Member of Parliament, Ann Widdecombe could be sabotaged using a really fun URL hack. By changing the text in the URLs of Widdecombe’s photo gallery, the on-site photo captions themselves also changed; with potentially obscene consequences.

Secondly, Phelps talks about the “recipe for confusion — and maybe legal issues, if someone can insert a libelous URL into one of your stories and spread it around” but he doesn’t clarify who is at risk from those legal issues. In fact, it’s highly unlikely that a news organization could be found liable for a URL that is hacked by a third party. Generally speaking, you can’t be held responsible for a libel you neither wrote or published. (News organizations can, of course, be liable for URLs they create themselves, as I explained last year).

Really, the biggest risk from URL spoofing lies not for the news organizations but for the pranksters themselves, and anyone unfortunate enough to fall for the prank and retweet a libelous link. This I know from bitter experience.

Back in 2003 – still a young, smart-ass columnist for Media Guardian, and editor of a satirical ezine called The Friday Thing – I stumbled across what I thought was a great piece of gossip. A very famous British sportsman – who should definitely not be named here – had apparently been conducting a sordid affair, and had secured a legal injunction to prevent UK newspaper from writing about it. Being a smart-ass, I wrote a column for the Guardian pointing out the ludicrousness of the injunction system, given that foreign newspapers were free to write about the story with impunity. Thinking myself far cleverer than I was, I then wrote a follow up story in The Friday Thing, linking to the foreign coverage of the story.

It was at this point I made an idiotic mistake: I decided to include the sportsman’s name in the short URL linking to the foreign coverage. Less than 24 hours later, I received a letter from a very large London law firm informing me that I was being sued for libeling their client, and that they would be pressing the English High Court to charge me with contempt of court (maximum sentence: about ten years in jail) for breaching the injunction. It took a year, and thousands of pounds in legal fees, to convince them to drop the case, on the grounds that I had no money for their client to win in damages.

Lesson one: URLs can be libelous too.

And it gets worse: in most jurisdictions repeating a libel is considered almost as serious (if not actually as serious) as the initial publication. In theory, anyone who retweets or quotes or simply links to a libelous URL could also find themselves on the receiving end of a libel suit.

Lesson two: if a URL seems too funny to be true, it’s probably a good idea not to forward it around.

Article courtesy of TechCrunch

Web developer Elliott Kember checks in to tell us:

Hey guys,

Not technically tech news, but I thought I’d share a cool hack we did last night: bieber.ly

It’s a Justin Bieber URL shortener. Pretty awful right?

Thanks,
Elliott

Yes, Elliott, yes it is.

Update: it works, captain, it works!

Article courtesy of TechCrunch

Earlier today, Google formally released Goo.gl, their URL-shortener, to the public. They’re calling it the “stablest, most secure, and fastest URL shortener on the web.” But it also may be the coolest thanks to an easter egg.

As Google’s Matt Cutts’ just tweeted out, if you simply add “.qr” to the end of any goo.gl URL, it will create a QR code. Scanning this with any QR code reader will take you to the URL.

So, for example, this URL: goo.gl/umo0, is the shortened link for this post. If I make it: goo.gl/umo0.qr, I’ll get the image above.

This functionality actually isn’t entirely new — but previously it was way too hard to use goo.gl (it was limited to a few Google products). Now that more people will likely be using goo.gl, this is very useful and worth pointing out again.

These QR codes are great for mobile use, and Google in particular has been using them a lot for things such as easy installation of Android apps.

Article courtesy of TechCrunch