Want to highlight a helpful answer? Upvote!

Did someone help you, or did an answer or User Tip resolve your issue? Upvote by selecting the upvote arrow. Your feedback helps others! Learn more about when to upvote >

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Google results links not working

Anyone else finding that (since upgrading to Yosemite - as far as I can tell) the links returned by a Google search intermittently all fail… "http://www.xxx.xxx could not be opened because the page cannot be found on that server" (or similar)?


A second click on the link (on the Google results page) usually goes right to the page. As does clicking on all other links - anywhere.


Surely it cannot be a failure of Google?


TA!

iMac with Retina 5K display, OS X Yosemite (10.10.3), Clean machine... no haxies; no Microsoft etc

Posted on May 15, 2015 7:13 AM

Reply
22 replies

Jul 30, 2017 11:35 PM in response to Mark Sealey

Same thing happens to me and im on El Capitan

I notice the same with the three or so images google also sometimes shows on a search page, which also dont lead anywhere

One thing i would like to say, after reading about this problem of links being unclickable or not leading anywhere in google on Apple, Mozilla, and even Google Chrome Help Forums, is that the problem is extending even to Google's own Chrome Browser

I would say that fixes should not be left to the browser developers, and that Google itself should stop just writing whatever code it wants and expecting the browsers to adapt to make themself compatible

It is Google itself, who should be adapting to make sure its search website works in all broswers, just like other webmasters do. It is the job of the website owner to make its website compatible with all browsers, and it is not the job of the browser developers to change their code when google updates its pages. Google should take responsibility and stop bullying everybody into fine tuning their websites and apps to googles tastes.

Google blogger makes DIV tags instead of P tags breaking the same rules of XHTML that google demands from its users, but doesn't use itself.

I think the problem lies with the fact that google doesnt have any feedback, nor do google help forums work well as its a mystery hjow to comment on a thread, because its a mystery to join a gthread, and a mystery to actually create a thread. there are no create thread or comment buttons unless you have joined that topic, and there are no 'join topic' buttons to join it with. except once in a while mysteriously you find yourself able to join a conversation topic.. but mostly you surf around trying to figure out how on earth everybody else managed to post something


So Google are not home when it comes to getting some feedback to them, they are deaf dumb and blind

Its not just safari, its chrome, vivaldi, IE, firefox...

So its GOOGLE problem, not Apple problem

May 15, 2015 5:03 PM in response to Linc Davis

Thanks, Linc


Yes, I saw that and tried what Apple themselves suggested.


I particularly tried removing Google cookies in Privacy > Details.


No good.


It's the oddest thing: These links - only on Google's results page(s) are the only ones that ever fail.


All other links are quick and infallible. All. Always. It's only Google!


I'm thinking that the way Google builds the links as arguments after a 'url?' parameter may be responsible?


That (the first result on their page) fails!


But only the first time. If I let it time out, produce the error and reload the (Google results) page, I'm OK again!

May 15, 2015 5:44 PM in response to Mark Sealey

Please read this whole message before doing anything.

This procedure is a diagnostic test. It’s unlikely to solve your problem. Don’t be disappointed when you find that nothing has changed after you complete it.

The purpose of the test is to determine whether the problem is caused by third-party software that loads automatically at startup or login, by a peripheral device, by a font conflict, or by corruption of the file system or of certain system caches.

Disconnect all wired peripherals except those needed for the test, and remove all aftermarket expansion cards, if applicable. Start up in safe mode and log in to the account with the problem.

Note: If FileVault is enabled in OS X 10.9 or earlier, or if a firmware password is set, or if the startup volume is a software RAID, you can’t do this. Ask for further instructions.

Safe mode is much slower to start up and run than normal, with limited graphics performance, and some things won’t work at all, including sound output and Wi-Fi on certain models. The next normal startup may also be somewhat slow.

The login screen appears even if you usually login automatically. You must know your login password in order to log in. If you’ve forgotten the password, you will need to reset it before you begin.

Test while in safe mode. Same problem?

After testing, restart as usual (not in safe mode) and verify that you still have the problem. Post the results of the test.

May 15, 2015 9:51 PM in response to Mark Sealey

Start up in Recovery mode. In the OS X Utilities screen, select Get Help Online. A clean copy of Safari will launch. No plugins, such as Flash, will be available. While in Recovery, you'll have no access to your saved bookmarks or passwords, so make a note of those before you begin, if they're needed for the test.

Test. After testing, restart as usual and post the results.

May 16, 2015 8:55 AM in response to Linc Davis

Linc,


I was beginning to think the same thing, too; thanks.


Though I've tested with other browsers and don't seem experience the failures - in FF (38), for example.


Safari has but one extension: 1Password 5.


I like what you say about the ISP - AT&T UVerse - though I think I'd need a month of tranquilizers and some very strong liquor before they'd really be able to help.


What don't you like about OpenDNS?


Alternative(s)?


I suppose I could put back AT&T's DNS IP addresses.


Though why on earth would resolution work for everything except just Google search results whose URLs are built as an argument in the link?


Your help and suggestions appreciated.

May 16, 2015 9:19 AM in response to Mark Sealey

This is a comment on OpenDNS and other public domain-name system (DNS) services, such as Google DNS. You should use such a service if it solves a problem for you, and not if it creates problems you don't already have. To summarize:

☞ Using public DNS will probably not make your network faster, and may make it slower.

☞ It will probably not stop your browser from being redirected when you try to connect to a valid web address.

☞ It will not make you safer from malware attacks.

☞ It could cause confidential information to be compromised.

☞ It has other privacy implications that you should be aware of.

A DNS server resolves the human-readable "domain name" of an Internet host, such as www.apple.com, to the numerical address by which that host can be reached. The process is analogous to looking up a phone number by name. There is no chance that changing the DNS server you use will have any effect on a network problem not related to name resolution.

There are two valid reasons why you might want to use a public DNS service:

☞ The DNS servers provided by your ISP are misconfigured (perhaps deliberately) or don't perform well.

☞ You have a use for the filtering controls provided by OpenDNS and others.

Although some DNS services are touted as responding faster than others, there will be no noticeable difference if your ISP is delivering what you pay for. Most likely, the difference in response time among the DNS servers available to you is on the order of a hundredth of a second or less. But under some conditions, public DNS will significantly slow down network performance. Here is a case in point.

A content-distribution network (CDN), such as the one used by Apple to deliver software updates and iTunes content, relies on the location of the DNS server to optimize performance. If your query goes to a distant server, you may get slow downloads of Apple content, among other things. From the report of a test carried out by a networking consultant:

We listed 9 CDNs that would benefit from supporting/using edns-client-subnet, and only two actually support edns-client-subnet: CDN77 and ChinaCache. Others, including Akamai, Internap and CDNetworks, do not currently. This really is too bad, because from the performance data we collected, it is clear these CDNs deliver (much) worse performance currently in many countries to Google DNS and OpenDNS users.

Another reason often given for using public DNS is to avoid "redirection," that is, false results from a query for a valid domain name. Ethical ISP's do not intentionally redirect valid DNS queries, though it might happen unintentionally because of a misconfiguration; for example, because the address of a network host has recently changed, or because of a "poisoning" attack on the DNS server. Note that many ISP's may, and OpenDNS certainly will, redirect invalid queries to ad sites, in violation of published standards for DNS.

Recently, a few low-quality commercial ISP's such as "CenturyLink" have taken to deliberately redirecting DNS queries for some domains, such as search engines. Do not tolerate this practice. If your ISP is doing it, then you should demand that the redirection be stopped, or else switch to another ISP.

Some ISP's have been said to route all DNS queries to their own name servers, regardless of where the queries were directed—another intolerable practice. I haven't heard that any commercial ISP is now doing this, but if yours is, you won't be able to use a public DNS service, even if you change the network settings on your computer or router.

Of course, if your Internet access is provided by an employer or institution, rather than by a commercial ISP, then you have to take whatever you get.

The claims on the OpenDNS website that it blocks malware attacks are false advertising. A DNS service does not and cannot block anything. All it can do is to selectively refuse to answer queries. It's trivial for a malware attacker to evade such controls. It's just as easy to evade the parental controls offered by OpenDNS. Nevertheless, you may find those control features useful, despite their limitations. Here is an example of an ASC user who had undesirable results from OpenDNS content filtering.

If you need to switch DNS providers because of a misconfiguration of your ISP's servers, the change will most likely only need to be temporary. The problem may be resolved automatically within a matter of hours.

If you're considering whether to use public DNS, such as OpenDNS, on a long-term basis, you should take into account the privacy implications. As a user of the free service, you are not an OpenDNS customer, and the service provider—a for-profit corporation—doesn't have a contract with you. The marketers to whom OpenDNS sells access and information are its customers.

OpenDNS will know, and store, the address of every Internet server you use. This is from its privacy policy:

When you use our Services, OpenDNS stores certain DNS, IP address and related information about you to improve the quality of our Service, to provide you with Services and for internal business and analysis purposes.

Concerning personal information, the policy states:

...[I]t is disclosed to entities that perform marketing services on our behalf or to other entities with whom we have joint marketing agreements...

You can't opt out of those disclosures. Read the privacy policy carefully and draw your own conclusions. The privacy policy of Google DNS seems to be somewhat more benign, but again, you should judge for yourself.

That's not the worst of it, though. The practice of hijacking nonexistent domains followed by most public DNS services could result in leaking confidential information to a hacker:

For example, consider the "same origin trust model" used for Web cookies. If you're holding a cookie for GOOGLE.COM and you can be fooled into following a link to KJHSDFKJHSKJHMJHER.GOOGLE.COM, and the resulting NXDOMAIN response is remapped into a positive answer to some advertising server, then you're going to send your cookie to that advertising server when you send your HTTP GET request there. Not such a bad thing for a GOOGLE.COM cookie, but a real problem for a BANKOFAMERICA.COM cookie.

NXDOMAIN remapping is not something that only happens when you randomly mistype a domain name. It can be exploited deliberately by malicious links placed on any web page. In the case of OpenDNS, the result would be that a cookie intended for another server would be sent to the OpenDNS web server instead. A rogue OpenDNS employee, or anyone who managed to break into the web server, might then be able to impersonate you on another website. If this scenario seems far-fetched, it's the stuff that network exploits are made of.

See also a brief, and somewhat outdated, critique of OpenDNS on a Harvard Law School blog, with a response from the company's founder.

Google results links not working

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.