Do images need to be static and with a standard extension?

[shaunm]

Hi,

As part of a recent IIS platform change, all the image URLs on the site are now ending with .ashx and some parameters after that. These images URLs used to be .png or .gif. I don't know what kind of advantage or disadvantage it has. I found them through Screaming from which never pulled image URLs before for me. So, if I'm not wrong, now the images are treated as any other normal HTML pages and Google might crawl them and index them too for a Web search right? What's it with the .ashx by the way?

Thanks for the help!

[goodroi]

Implementing a large site-wide change from a simple & established protocol to a new and less common protocol rarely helps you. It is usually best to keep things as simple and plain as possible aka keep your image files in png & gif.

[shaunm]

Thanks. But why should a platform like IIS/.Net uses such weird URLs for images?

[Robert Charlton]

So, if I'm not wrong, now the images are treated as any other normal HTML pages and Google might crawl them and index them too for a Web search right? What's it with the .ashx by the way?

shaunm, I know very little about asp.net, and most references on the topic assume a bunch of vocabulary that I'm not familiar with... but I'm pretty sure that...

- .ashx files are intermediate files, (technically called Handlers) used to call other files within asp.net...

- .ashx files are not intended to be opened in a web browser. This suggests to me that you don't want Google to be indexing them.

Beyond that, you need someone familiar with asp.net to guide you.

[shaunm]

Thanks :-)

#1<img src='http://www.example.com/-/images/logo1024×768.ashx?h=85&amp;w=236&amp;la=en&amp;hash=7E71515E5E12' alt=''This is logo" />
#2<img src='http://www.example.com/images/companylogo.jpg' alt=''This is logo" />

I've seen only #2 in use as long as I can remember (may be not). My concern is if the images are doing their purpose from appearing in Google image search to creating a relationship with the content through ALT (even if a bit). Also, whether if that makes sense for Google and other search engines to crawl and disguise as images rather than some complex .net pages. I'm not familiar with this topic either. May be I should have created this under IIS discussions?

[tangor]

This is an IIS asp.net question. What I'd like to know is what part of your "platform change" caused this? Images, in general, should be static images with known extensions and without need of a "handler" files to display them. Figure that part out. In the long run I think g, or any search engine, will frown at an intermediate layer between it and the content to be indexed.

[Ocean10000]

As an IIS admin, the only time I put images behind a handler (.ashx) is when I want more control of how the image is processed. I do not want to provide direct access to the image. By default images are handled by the static file handler, in iis 7 and up, which is designed for speed and has very little overhead and can be handled in kernel space.

Ashx is the low level handler which provides a simple programing interface to decide what to do with the request. I have used it myself along with iis rewrite to gain better control of who could view images off my website. Most of the time I used it to block hotlinking several popular images on my website, from being used on some seedier parts of the web. I know my preference is to not show ".asxh" extensions at all, which is why I have rules to map them to properly named virtual files. I am not sure why the application is not doing this second step as it is usually better SEO wise.

[shaunm]

Thanks @Ocean1000 & @tangor

This is an IIS asp.net question. What I'd like to know is what part of your "platform change" caused this?

We recently moved to Sitecore CMS and it's on IIS 8.5.

As an IIS admin, the only time I put images behind a handler (.ashx) is when I want more control of how the image is processed. I do not want to provide direct access to the image.

In the HTML source of my homepages I see more than 50 .ashx URLs leading to images on the pages like company logo, main banner image and footer images etc. Most of these .ashx image URLs are including weird parameters and are almost 150 characters long. So, each and every image on the site is now on .ashx URL with and without parameters.

Again, is that a bad approach? Or something that has little to worry about when it comes to how the search engines crawl/treat them and image SEO? And most importantly the page speed? Thanks!

[Andy Langton]

As long as the content type is correct, it doesn't matter what extension the files have. You'll find many images indexed in Google images with an ashx extension:

[google.co.uk...] (can't do a direct filetype: search on Google images, unfortunately).

No search engines of note categorises pages based on the extension in the href, because this is totally unreliable. It works both ways, incidentally:

filetype:jpg in a web search will show you HTML content with a .jpg extension [google.co.uk]

As long as the URLs are static (i.e. do not change from one request or visit to another), the content-type is correct and your server has sufficient resources to avoid slow-down when dynamically serving images, I would be inclined to forget about it. If there's a 'checkbox' type fix, I would go for it, but if it's fundamentally how your CMS handles it, I think it's unlikely to be worth significant effort to change.

[shaunm]

Thanks @Andy_Langton,

That was helpful. I never really searched for image file types in Google web search. That's really bad development in play. Why should name your non-html pages something as .aspx, .html or html pages as .jpg?

Anyway, it's good to see the dynamic .ashx images in Google image search. But still I'm not entirely clear why a popular CMS should create some complex URL structures avoiding very common prototypes. May be that's because of the size of the site and thousands of images to call for dynamically?

[Andy Langton]

But still I'm not entirely clear why a popular CMS should create some complex URL structures avoiding very common prototypes.

It's just a lack of separation of the back-end coding and the frontend URLs. The idea is to have control over aspects of the image (e.g. size).

For instance, on an Apache server I could dynamically rewrite URLs to resize images like so: /img/130w250h/filename.jpg - exactly the same processing could be happening behind the scenes, but just with friendlier URLs.

That's really bad development in play.

I don't think it really is - there's no reason to suppose that the last characters in a URL mean a certain type of content is there. It's just a hangover from the days when websites might literally be a bunch of shared files in a directory and people expected things to behave the same on the web as with local files. But URLs are an entirely separate system. So, Wikipedia's image information pages end with the image filename - this seems reasonable enough to me!