feat(gatsby-plugin-canonical-urls): add option to strip query string

[Ehesp]

[gatsby-plugin-canonical-urls]

cc @sidharthachatterjee @MarkSalabutin

Description

This is a fairly opinionated PR. I can flip the logic if needed 👍

Issue #12709 makes a good point about the search params (e.g. ?tag=foobar) being added to the canonical urls this plugin generates. From my limited SEO knowledge, the search params being included makes this plugin somewhat redundant.

A canonical tag (aka "rel canonical") is a way of telling search engines that a specific URL represents the master copy of a page. Using the canonical tag prevents problems caused by identical or "duplicate" content appearing on multiple URLs. Practically speaking, the canonical tag tells search engines which version of a URL you want to appear in search results. https://moz.com/learn/seo/canonicalization

Lets say I have the following page: /blog

If I add a tagging system, and have functionality for /blog?tag=foobar, search engines will still index this as a separate page, even with this plugin installed. The master reference is in-fact /blog. This may not be the case all of the time, but I can't think of many cases, especially in Gatsby, where you'd want a "duplicate page" to be indexed when search params are different - it'd make more sense to create a totally different page/route.

These changes means search params won't be added by default, but gives the user the ability to set a flag adding them on. As mentioned above, I can flip this logic if you guys think it's too opinionated to do that 😄

It would be good for someone else to test this, as breaking this functionality can have pretty serious consequences for websites SEO!

Related Issues

#12709

[pieh]

Please don't change version and changelog manually - this happen automatically when we publish new release.

Given breaking nature of proposed change (in current shape) - I would vote for introducing option to strip search / query from canonical link (so it's not breaking for anyone who relies on current behavior) and do some research for any cases when having query string is desirable and figure out what's best default behavior - if we will end up deciding that striping search by default is best we would just flip default value for strip option and bump major version then.

[Ehesp]

@pieh no problem will revert the changelog/package.json changes.

That makes sense, I'll revert the logic so the params can be excluded.

[Ehesp]

Updated to exclude search params if search is specifically set to false.

[pieh]

What do you think about renaming stripSearchParam to stripQueryString as query string is actual name of that part of urls (so technically more correct :P)?

Other than that, it LGTM

[LekoArts]

@pieh changed the name :D

[pieh]

LGTM! Thanks @Ehesp and @LekoArts!