Add support for vanity names

[jargharg]

This PR adds support for vanity names, as referenced in the Sanity docs here.

When passing in a vanityName prop, that string is appended to the URL before the query params.

[jargharg]

@coreyward any chance you could take a look at this please? Would be good to get into my project and useful for others too I imagine — helps with SEO

[coreyward]

Is there compelling evidence that this is actually beneficial given the context (images served from a third-party domain)? From what I can ascertain, this is actually a net negative:

1. Any SEO benefit is conferred to the host of the image (Sanity), not the website linking to the image
2. The addition of the vanity name ends up inadvertently acting as a cache bust
3. The vanity name winds up repeated in the source, bloating the page needlessly

Additionally, it seems that file names are generally regarded as a much weaker signal than alt text, surrounding content, titles and headers, and relevancy to the page content.

I'm generally hesitant to add support for something that's unlikely to benefit users, especially if it bloats the library.

[jargharg]

Hi Corey

1. You might be right. I can't find any information on this.
2. This is opt-in only, so yes it might cache-bust in the case of a codebase being updated to use the new functionality. If a dev upgraded to the new package and didn't make any code updates, nothing would change on the front end. There is a test for this included in the PR.
3. Ok, needless if this doesn't affect SEO — but the dev can choose not to include it if performance is a bigger concern than SEO.

A client specifically asked for original filenames to be included in the source code to improve SEO, so I made this change and thought it would be useful for other users of the package — especially as Sanity has this functionality and explicitly states that it's useful for SEO (link).

Filenames are definitely weaker than the other signifiers you list but from what I can gather, they still count. Google recommend it at least.

Thanks

[coreyward]

Okay, that Google link is helpful. I can see this being of some value in some scenarios. The value is relatively low (as Google says, "the filename can give Google very light clues about the subject matter of the image"), and the approach you're using here makes it a cross-cutting concern of the library, requiring a lot of the codebase to be aware of this behavior. That's not ideal, so I'll need to think about how to handle this better.

For my own edification, in this client project, are the vanity names being set to something that looks like a sensible image name including the format? For example, something like "black-lab-puppy.jpg"? Or are the editors doing something more keyword-heavy like "black lab puppy, dogs, puppies"?

[jargharg]

Got ya. Well let me know if / how I can help any further.

So the client is just uploading pictures with a descriptive filename, then that filename is pulled through to the front end, rather than adding keywords after the fact. You can see it in use here (looks like they're not filling in the alt tags, which would be much better for SEO by all accounts!)

[coreyward]

Out of curiosity I poked about a bit and it looks like the alt text is retrieving the image on Google image search, but the vanity name is not. I checked the oldest post just to have a higher chance of it being indexed, too.

Product name + alt text for primary image returns a result

Product name + vanity image filename doesn't lead to an appearance in search results

Meanwhile, including a "Sanity" prefix to the search query results in the target image being returned in the first position for either the alt text or vanity name. This confirms my expectation that this does more to benefit the image host (Sanity) than the website displaying the image. In fact, it seems to do very little for the website displaying the image—Google doesn't associate it with the website in terms of the query.

"Sanity" + alt text for primary image returns image as 1st result

"Sanity" + vanity image filename returns image as 1st result

This doesn't mean it's not worth implementing, but hopefully it does provide some context for anybody that is considering implementing it so they can reason about the anticipated benefits (likely much greater for those using a custom asset domain on a Sanity enterprise plan).

---

I recently released a new version of Sanity Image that extracts the url-builder logic into a separate package for use outside of React. Since it handles all of the URL building, this feature would need to be applied to it as well. It might be some months before I can get back to this work, but if anybody else comes across this and is blocked on it, please drop a comment with a polite nudge.