@Maxime_Breton_V It will vary based on theme, but yes, your red arrow would be correct.
# {{ collection.title }}
will become
{% if collection.id or collection.products.size > 0 %}
# {{ collection.title }}
{% endif %}
Hi @Allan-EP ,
Thanks for this code. @gregbernhardt thanks for all your help too. I feel you are the only Shopify Staff member trying to help up. The other no index code solution messed with my sites menu and breadcrumbs. Normal for me on 11/28 was 9K Non-Indexed and 4K Indexed. Today I’m at 2.1 Million NI and 1.7M indexed). The attack started 11/29. I contacted Shopify right away. Shopify is ignoring me as well and telling me to go to a theme developer. @Shay my ticket numbers are 34543316 & 34784932.
I need some help finding where to put this code in my theme if there is any one that uses snippets… Here are a couple screen shots. I’m not sure which snippet the code needs to be in. I think mine is in the collection-item.liquid? It’s the only place I find {{ collection_title }}.
If someone has actually used a Shopify Expert who knows exactly what to do to fix this problem, I’d LOVE to know their contact info. I have a feeling they are trying to figure it out too!
FYI, I’ve read all the posts in both community threads and have read all the suggested articles, so I’m up to speed. This is something that Shopify can prevent/fix and are staying silent about it. I hope they are working on a solution on their end. This is maddening! OK, rant over.
@Vicky6 Can you attach a screenshot of collection-template.liquid under Sections? You’ll either add the code there or in the snippet, but I suspect it’s the section.
@Allan-EP I checked. No {{ collection_title }} in that section. Thanks for your speedy help!
It may not be exactly collection_title like in your snippet. What you’re really looking for is collection.title
@Allan-EP collection.title wasn’t in collection-template.liquid but I did find it in collection-header.liquid. It was too large to screenshot. Here is the code for that section. Thanks for taking a look if you have time.
{% if section.settings.display_image_cat %}
{% if section.settings.img_cat != blank %}
<img src=“{{ section.settings.img_cat | img_url :“master”}}” alt=“{{ collection.title | split: ‘|’ | first }}” />
{% else %}
{% capture current %}{% cycle 2%}{% endcapture %}
{{ ‘lifestyle-’ | append: current | placeholder_svg_tag: ‘placeholder-svg’ }}
{% endif %}
{% endif %}
{% if settings.enable_multilang %}
{{ collection.title | split: ‘|’ | first }}
{{ collection.title | split: ‘|’ | last }}
{% else %}
{% endif %}
{% if collection.description != ‘’ %}
{% if settings.enable_multilang %}
{% else %}
{% endif %}
{% endif %}
{% schema %}
{
“name”: “Collection Header”,
“settings”: [
{
“type”: “checkbox”,
“id”: “display_image_cat”,
“label”: “Display Image Category?”,
“default”: true
},
{
“type”: “image_picker”,
“id”: “img_cat”,
“label”: “Image Category”
}
]
}
{% endschema %}
It’s probably this line:
The “if” line goes above that and the “endif” line goes after it. I’d write the code fully out but am replying on my phone at an airport. 
Hello, Greg. Until Shopify patches this system-wide vulnerability, can we please have an official piece of code that has been vetted by Shopify Staff which we can implement into our stores — along with an official, easy-to-find Help Center article that clearly explains what the code is for, where to install it, and what its limitations might be?
Because as it stands, Shopify support agents are simply telling us (store owners) that this is essentially not a Shopify problem, even though it most certainly is. The agents are telling us to read articles on third-party sites, or “report the problem to Google”, or refer to the community forum, for answers. These types of directions from the support agents are nothing less than acts of passing-the-buck, in my opinion. Shopify needs to own this spam issue. And it is irrelevant that similar problems may, or may not, be happening on other platforms. Shopify needs to do better; that is why we chose to host our store here — for the time being.
It is inexcusable that Shopify has not implemented a system-wide measure to prevent these spam pages from being generated by now. Based on the accounts that other users have posted, and based on my own experience and research, this spam problem has been going on for several weeks, if not months. Ultimately, it is Shopify’s system that is allowing these spam pages to be generated (and yes, they are pages, each with their own individual URLs), so it is Shopify, and only Shopify, that should be responsible for fixing the problem. It is not the store owner’s responsibility. With all of the resources that Shopify has, why has a fix not been implemented by now?
In the meantime, I await your reply with official Shopify-vetted code which we can use as a temporary bandage.
Been with Shopify chat support for 2 hours now, and they still seem like they have no idea what i am talking about. This is embarrassing since the problem have existed since September.
My solution so far is this:
Disallow: /collections/vendors*
which apparently doesn’t work, since Google will allow a disallow when it includes a link
making a “temporary removals → New request” on /collections/vendors prefix.
Which will help, but not fix the issue.
What other measurements could be taken? (i see two solutions in the thread, one by @Allan-EP and one by @DaveSweetCure
@greg - you mention that you are not directly involved in this issue, but simply trying to help. This is appreciated, but why are no representatives that are involved in this issue commenting in this thread?
We are all affected and in the dark as to how to proceed.
If it helps you any the solution I posted seems to working in the sense the number of these pages indexed by Google is dropping in webmasters / Google console. And the total number of these pages being found and being crawled hasn’t increased (so fix preventing the print of query seems to have helped prevent anymore of these links being created as its pointless for the attacking site to do so).
The only downside is that the links google found and crawled before our fixes, google will still assume they are ‘live’ as it’s not possible to serve a 404.
Interestingly since applying the fix and the total indexed page count dropping, our organic hits have increased - maybe a coincidence - but concerning if potentially if the two are linked. (NOTE: Our organic hits aren’t anything to write home about and this is just for our UK site).
Have attached a screenshot which shows the indexed page count dropping with the fixes we implemented and interestingly the organic hits increasing.
For reference the site is around 250 unique pages, but I am aware of additional pages / dupes we need to sort that inflates our page count. That said we still have some way to go from the currently indexed 52k of pages.
NOTE: Do take note of Greg’s comment regarding not including the /vendors/ directory in robots.txt until after Google has removed the pages from it’s index as you do want Google to crawl them to read the no index command in the page.
As mentioned in previous posts this could be such as simple fix, vendors functionality could be a simple tick box Y / N if you want to use or not. If not, Shopify could serve a 404 page to all hits on the vendors directory.
@DaveSweetCures can you not use the “removals → temporary removals → New reques” feature in Google Search Console to remove the already crawled sites?
@Jesper_Skaane_B - Yes you can and we did that as well, only issue being is without the other fixes, then the external links that create the pages will still continue to be created.
The temporary removal is also just a bandaid to allow sites time to fix issues. So technically speaking the page still exists - and is “potentially indexable”, you’ve just requested it to be temporarily hidden. Google console also lags behind an changes considerably.
Ultimately, the not indexed pages count won’t drop until one of the following things happens,
*BTW, I can see Shopify’s point of view this being a theme issue, as had some of these fixes being in place in the theme, arguably we would NOT be in the position we are now. As there would have been no point of the attacking site linking to us in the first place - had the query not printed in the page content.
*BTW, I can see Shopify’s point of view this being a theme issue, as had some of these fixes being in place in the theme, arguably we would NOT be in the position we are now. As there would have been no point of the attacking site linking to us in the first place - had the query not printed in the page content.
@DaveSweetCures thanks for clearing that up. one would hope that shopify steps up. one of the reasons i am on shopify and not wordspress, is that one would think that there would be people handling these kinds of things.
in regards to it being a theme issue. Sure. however i am on a shopify native theme. so i am going to kick that ball right back to Shopify.
wow ok, so it’s even an issue with native themes. OK, be worth keeping an eye on updates for native themes - as any fixes may herald a different solution for those with themes created elsewhere.
@DaveSweetCures Shopifys goto is always “third party app” or “theme issue” -__-’
I am on a theme called Supply, which is native shopify theme. i should be eligible for some dev. work, which i am waiting for answer on. but knowing shopify, it probably falls out of the scope of what they offer.
You can disavow all you want, it won’t stop this. Every shop is experienced thousand or millions of new indexed pages daily, as you can see across these boards. It’s an exploit that Shopify is choosing to ignore rather than address.
The only solution that I’ve found so far from @Jizo_Inagaki is to do the following:
Go to the theme.liquid file and enter the following code in the section:
{%- if request.path == ‘/collections/vendors’ and collection.all_products_count == 0 -%}
{%- endif -%}
This should add a ‘noindex’ tag to the collection/vendors pages being exploited. As your site is crawled in the future, it will remove current pages and stop future ones from being indexed on your site.
Shopify is choosing to ignore this, so hopefully that stops the bleeding for now.
@Barked201 seems straight forward. how does this difference from adding Disallow: /collections/vendors* in robots? (if it does)
If you block with robots.txt it will prevent Google from crawling those pages to ‘noindex’, I believe. My understanding is that if they’re already indexed, which most are, and you block with robots.txt, Google won’t be able to crawl again to remove them from index.
Adding the code above will allow Google to crawl these pages and adhere to the ‘noindex’ rules, removing it from index and preventing any others from indexing in the future.
I tested a live URL on my site and it seems to be working - I just have to wait for them all to be crawled again, which can take a while.
