A client had an accidental deploy which resulted in a staging noindex going to production:
By the time it appeared in Google Search Console it was a non-issue and had been resolved by a subsequent deploy. But while submitting a fix for Validation, I saw a very interesting option which turned out to be true:
I could now limit the validation to one of the XML sitemaps.
Here is all you need to remember from this post:
- You can limit Search Console’s issue validation to specific Sitemaps submitted in Google Search Console.
- These Sitemaps don’t have to currently exist.
This is one of those things that seems to have been a quiet quality-of-life improvement. Perhaps I was too inattentive before (I’m hoping you were too).
Put simply, you can now choose which URLs you draw Google’s attention to regarding these fixes. If you have an issue spanning multiple templates, you can submit them as fixed as-you-go, rather than waiting for the issue to be fixed across all templates.
Previously you could attempt to utilise subfolder based Search Console profiles to do this (though you had to be lucky with issues coinciding with URL paths).
The sitemap method has the advantage of allowing arbitrary URL inclusion. You can submit some, but not all URLs.
Better Validation Method
- Create a Sitemap (XML or TXT or whatever), containing URLs of the issue that’s partially fixed.
- Submit it to Google Search Console.
- Wait until the 📊 icon appears under Sitemaps, or on the individual Sitemap page (see below). At this point it’s ready to be used for this purpose.
- View the appropriate issue while filtered to this custom sitemap and press the VALIDATE FIX button.
At this point, it will appear as an option under the ‘All known pages 🔽’ heading:
Once you have filtered the issue to the sitemap of your choice, you are able to press the button:
A couple of things to remember:
- Google’s 1k sample URLs probably aren’t going to be that helpful if they have identified over 1k URLs sitewide. The list you are creating should be done independently to account for this.
- You don’t have to submit everything at once, but can limit it to the ‘fixed’ URLs you care about the most (for whatever reason).
- You can do this in tiny batches.
This is only going to be useful for those validation issues where the thing they are complaining about has subsequently changed since they last crawled it.
Despite this, I hope you’ll agree that as a technique this might prove useful to you in future. If you do, share the post so I can take credit in Google updating their interface and documentation.
Thanks for reading and have fun!
Not New
I did check to see how long I’d missed this for. This is transparently in the documentation – Validate your fixes – which is a fragment referenced from here.
The relevant parts:
Pro tip: Validate your fixes by sitemap To speed up a fix request, create and submit a sitemap containing only your most important pages, then filter the report by that sitemap before requesting a fix validation. A validation request against a subset of your affected URLs can complete faster than a request that includes all affected URLs on your site.
⚠️ If you are filtered to a specific sitemap in your report, the validation will apply only to items in the sitemap at the time you requested validation. This might be what you want, or it might not. Just be aware of it.
Thankfully, this doesn’t appear to be ancient, but was something I’d missed over the holidays.
~
So basically GSC does not mind if the URLs are in more than one site map at a time?
only for validating issues.
Don’t do this with your regular sitemaps
No real impact to have an URL listed in multiple sitemaps, Google will streamline its own crawl queue anyway.
How long does it take the to show up? I’ve been waiting WEEKS and the index coverage button is still grey
This is awesome! I love the creative approach and the sitemap titles lol
Hi
thank you for this tweak. Google said it is unnecessary to submit multiple sitemaps for different parts of the website. But this method is helpful in diagnosing indexing issues.