SEO and Images: the src URL changes at every build whenever you change max-width property

[fsgreco]

Summary

I fond that whenever I change the max-width property within the graphql query that gets the image, it slightly changes the URL of the source on the build. Despite the name of the image is the same.

Here is an example of how the URL changes

when I have the same image with (maxWidth: 1400):

And here with maxWidth: 1500:

From a SEO perspective it is not recommended to change the URL of the main "src" attribute inside img element. It's like telling Google that now there is a completely new images. (indeed this is also not recommended by Google (source1, source2)

For this example I use gatsby-source-wordpress but I think that this behavior is global and has to do with how webpack handle the images.

This is the query used for this example. The only change regards the maxWidth proprierty.

acf {
	img_copertina {
		localFile {
			childImageSharp {
				fluid(maxWidth: 1400){
					...GatsbyImageSharpFluid_tracedSVG
					src
				}
			}
		}
	}
}

Expected Behaviour

Since the image hasn't change it's name its url should remain the same even when it changes quality or width.

[jonniebigodes]

@anonimoconiglio i believe that's related to the build process. when you change the argument(variable) for fluid, gatsby during it's build process will re process the images and update the nodes information about the image. And that will result in the update on that path.

[fsgreco]

@jonniebigodes is it possible to prevent this behavior? I mean to not change the path of the image on build process whenever some variable change?

After all this could be a problem from a SEO point of view.
Indeed I realize about it because google images put a caption on my image that says "new" on it's SERP. And that was after the last commit/push (in which I had changed maxWidth only from 1400 to 1500).

In the current state I should decide to keep permanent all the variables (quality, max-width, etc).

[freiksenet]

There isn't a way to change this, sorry. If the parameters change, then Gatsby considers this to be a new image. We feel it's a correct behavior in this case, cause it also makes sense for caching (so you can have long term caching and not worry that the changed image won't be invalidated).

[fsgreco]

@freiksenet
I guess it's fine (I mean it makes sense from the technical point of view, due to the cache problem you mention, although from a different perspective it is not an actual "new" image), maybe it could be useful to point it out to prevent someone to change that parameters lightheartedly and lose his ranking with google images.

[freiksenet]

That is a good point, would you like to make a PR to the documentation to clarify that?

[fsgreco]

That is a good point, would you like to make a PR to the documentation to clarify that?

Yes, it would be a pleasure. Can you tell me where I should make the PR? Actually I never make a PR before :( (although I know the concept)

[polarathene]

The image name that gets output could use the hash for a cache key, but strip it for actual build output? Eg, cache-key.jpg (assuming that's the current approach) could then be made image-hash.jpg when moved to the public folder for CDN usage.

Then you're free to invalidate cache during build when parameters unrelated to the image output change, but the image itself if unchanged can retain the same filename.

Alternatively, I guess one could iterate through the images in post and get the image hashes, followed by searching for the url references to replace them and update the filename. Perhaps useful as a plugin, or final step after a build or before deploying.