Google Crawler. Searches the 100 first google results for some term
Some thoughts:


Usually when naming an interface, you want to give some hint as to what actions that interface describes.  Here I don't quite understand what implementing GoogleProxy should be able to do for the implementing class.  What do getting a response and parsing a URL have to do with a proxy? What do these methods have to do with Google specifically? Would this interface better be named as HttpClient or something like that which indicates that these are the methods that need to be implemented by a class to enable the request/response aspects of crawling?
You might consider adding @throws in your interface documentation for parseUrl().  Not that this really does anything, but perhaps at least it can drive code consistency in having implementing classes throw appropriate exceptions and might help when working in an IDE.
In your getHttpResponse() implementation, you are doing nothing to either handle underlying exceptions that can be thrown by the Guzzle Client or indicate that the function might throw (why no doc blocks in implementing class?).
You should namespace your interface file.
In your parseUrl(), I think it is problematic that you are parsing the query string into the same array that you put your parse_url() results into.  Why not just create a new array here to eliminate confusion over what your intent is and to eliminate any possibility of overwriting date in $link() (if you ever wanted to do anything else with that data.
Should you really throw an exception if the URL value in the query string is not valid? I would think that this could be an expected occurrence that you might need to handle as you have no control over this input. Does this really represent an unexpected state in your application as is often the intended use for throwing exceptions?
Should you add some validation for the parametric input to both of these functions (i.e. non-zero length string, properly formed URL). In your getHttpResponse() implementation you can get as far as attempting to make a (relatively expensive) call on a remote host even if you have an empty string or invalid URL passed to the method.  I generally think it good practice to enforce some basic level of validation on parameters passed to public methods, perhaps throwing InvalidArgumentException or similar before getting into method logic such that you are failing fast and failing loudly when bad input is passed.
From looking at your wider library on Github, it seems as if you are trying to work with dependency injection. If you want to be consistent in this approach, I would think your implementing classes would need to take on dependencies such as the Guzzle client in their constructors, as opposed to within the methods that are implementing the interface.
With the above thought in mind, I am actually not sure that what you have right now is even best modeled as an interface vs. class inheritance since all the proxy classes you currently have implemented don't really do much outside of implement these two methods.