| 2:29 am on Apr 23, 2013 (gmt 0)|
Obvious question first: Are the images being crawled?
Related questions: Are the full-size images attached to vanilla html links like
<a href = "imagefile.jpg"><img src = "thumbnail.jpg" blahblah></a>
I assume you've already checked for obvious booboos like accidentally roboting-out the /images/ directory, or attaching noindex headers to all jpg files. Show me someone who says they have never done anything even remotely resembling this, and I'll show you a barefaced liar ;)
:: trying very hard to avoid pursuing second-most-obvious line of questioning ::
| 4:21 am on Apr 23, 2013 (gmt 0)|
Very vanilla links. example
<a href="http://foo.com/image.jpg"><img src="http://foo.com/thumbnail.jpg" alt="Some alt" title="some title"/></a>
The old images linked this way are still being indexed, its just that new ones aren't.
| 4:58 am on Apr 23, 2013 (gmt 0)|
** asks question to all - might this be related to the reported update to Google image search? **
| 5:20 am on Apr 23, 2013 (gmt 0)|
Wouldn't you think that freestanding images would be just what g wants? If they're intended to be viewed in isolation, they don't really "belong" to a page in the way that <img src> images do. So the search engine doesn't even have to think about preserving a connection. And the "view original image" user experience is exactly the same as they'd get on the originating site.
Matter of fact, I recently created a whole slew of non-indexed dummy pages precisely to get rid of my old <a href> images.
| 5:39 am on Apr 23, 2013 (gmt 0)|
|Is it possible that I need a relative URL to get the linked image indexed? |
No, if you make the URL relative, all that will happen is the requesting user-agent has to pre-pend the current domain to the specified location, so unless you have the wrong domain or file path in the URL it doesn't matter if it's absolute or server relative.
Using an absolute URL will cause the user-agent to request exactly the location indicated.
Server Relative (full path from the root)
Using a server relative URL will cause the user-agent to request the location after pre-pending the current root/domain, so on example.com the requested location will be http://example.com/the-path/to/the-file.ext
Directory Relative (path from the current directory)
Using a directory relative location is one of the most mistake prone ways to do things, because the user-agent will request the location after pre-pending the current path. So:
If the user-agent is currently at http://example.com/ and sees the-file.ext it will request http://example.com/the-file.ext
If the user-agent is currently at http://example.com/the-path/ and sees the-file.ext it will request http://example.com/the-path/the-file.ext
If the user-agent is currently at http://example.com/the-path/to/ and sees the-file.ext it will request http://example.com/the-path/to/the-file.ext
People often run into issues with directory relative URLs, especially when moving files to different level directories and forgetting to change the directory relative URL to "point" to the actual location of the file they are trying to indicate should be requested from the new location of the page it's linked from. (I definitely do not recommend directory relative URLs personally.)
Either absolute or server relative should be fine as long as you have the actual path (/the-path/to/the-file.ext) correct and the domain name correct in the case of absolute, or the user-agent is visiting your site in the case of server relative.
| 12:49 pm on Apr 23, 2013 (gmt 0)|
I think TheOptimizationIdiot has the winner here as I have always found that absolute or server relative is really the only way to go as to not confuse the robots... nice job TOI... great explanation!
| 3:09 pm on Apr 23, 2013 (gmt 0)|
Thanks for the responses, I guess the juice doesn't pass through a link to an image the way it used to.