There are times that pesky image search results stick around on Google even when those images have been removed from the web (or at least you think they have been removed from the web). I’ve received many calls over the years about this very situation. And many times, the images that people want to remove are on third-party sites outside of that person’s control. For example, profile photos from Twitter, Facebook, images from articles that have been removed, etc.

Since the sites aren’t under your direct control, your options are limited. For example, for times you can’t directly access the third-party site and you can’t access the Google Search Console (GSC) property for the site to use the Removals tool. From an image search standpoint, it can unfortunately lag behind web search for updating and/or removing files. And that can result in images hanging around the search results when they really should be removed, which can be extremely frustrating.

So what can you do??

Well, as long as the image has been removed from the third-party page that contained it, or if the page has been entirely removed from that site, Google provides functionality for quickly removing that image from the search results. On that note, I find there’s a lot of confusion about the various tools Google provides for removals, and how to use them. I’ll explain more about that soon.

For this post, I’m going to show you how to remove an image from Google Images, when that image resides on a third-party site (out of your control). I’ll walk you through using the Outdated Content Tool to target those images and remove them from the image results.

The Removals Tools in GSC Versus The Outdated Content Tool
First, I know many people aren’t familiar with Google’s Outdated Content Tool, which has been around for a long time. It’s a publicly available tool that you can use to request removal of webpages or images (as long as that content has actually been removed). I have used this tool many times over the years when helping clients. And it’s important to understand that it’s different from the Removals tool in GSC.

It’s also important to note that the content you are attempting to remove from the search results must have been removed already from the third-party site for this tool to work. You cannot simply log into the tool and start nuking content from another site when that content still exists.

In the tool, you can request new removals (e.g. webpages or images) and you will also see previous requests and the status of those requests.

Again, this is different from the Removals Tool in GSC, where you can temporarily hide content from the search results from sites you control for six months (while you actually remove the content on your site). And if the content is removed behind the scenes, it will remain out of Google’s index, and out of its search results long-term (beyond the six-month temporary removal).

Adding More Confusion To The Removal Tools Situation
The new Removals Tool in GSC will also show you “outdated content removal requests” (which were submitted via the public Outdated Content Tool I mentioned earlier! So as a site owner, you can see any content that someone has attempted to remove on your site using the public tool.

Note, I would check this report soon… since you might be surprised what you find there. For example, I’ve seen people try to remove important files or directories from sites they don’t control using the tool. Scary, right? Of course, since the content was still present on the site, Google declined the removal request and nothing happened. But it’s still important to know what’s going on there.

For example, here is a screenshot showing three submitted requests flagging my client’s content as “explicit”. All three were denied by Google, but scary to think there was an attempt like that:

How To Remove An Image From Google Images Using The Outdated Content Tool
Now that I’ve covered the various removal tools from Google, I’m going to walk you through removing an image from Google Image Search. If you have an actual image you want removed, then now is a great time to use that image while following along.

Google provides a help document listing the necessary steps and I’ll walk you through those steps below (along with any tips I can provide along the way):

1. Go to Google Images and search for the image you want to remove.

2. From the search results, right-click on that image and select “Copy Link Address”. Don’t click the image… just right-click directly in the search results when you find the image.

3. I recommend creating a text file that contains the urls you want to remove. There may be more than one url when it’s all said and done and it’s best to store them in a file for future reference. Paste the url you just copied from the image search results into that text document.

4. There are times one image ends up being multiple images. That’s because some sites keep images in multiple sizes or at multiple urls. So, you want to make sure you copy all of those image urls for removal. If not, as one image is removed from the search results, another might take its place.

You can find other urls for the same image by right-clicking on the image in the search results and selecting “Search Google for Image”. If there are other sizes, click the links to view the image results for the other sizes. Then right-click and copy the urls like we did earlier (directly from the search results).

5. Go to the public Outdated Content Tool and paste the urls one by one into the tool and click “Request Removal”. You will need to enter each url separately. Note, I’m not actually submitting the form to remove the image from Google. It’s just an example for the tutorial. :)

Depending on the type of removal, you will see a different message. For example, if it’s just the image you are removing, and the page has been removed on the third-party site, then you will see a message explaining that the image is “no longer live on the website”. If it is gone, you can continue by clicking “Request removal”.

If you are removing an image that has been removed from a page, but the page still remains, you will see a different message. If the image has indeed been updated or removed from that page, then you should click “Yes” in the form and continue. And in case you’re wondering, the webpage isn’t going to be taken down… it’s just the image that will be purged. That’s what you want.

Congratulations, you have successfully requested removal of an image from Google Images! Well, sort of… Now you need to let Google do its thing and remove the images from Search. More about that next. You will see the status of “Pending” until the images are removed.

How Long Does It Take Before The Image Is Actually Removed? It’s Pretty Quick
When you request removal of an image, Google can work really fast. I’ve seen images removed within a day or so. You can always check the Outdated Content Tool to see the status of the removals. And you can obviously check Google Images to see if the images are indeed gone from the image search results. When the images are removed, you will see the status change from “Pending” to “Removed”.

And you will also see the type of removal requested. The status could be “Outdated page removal”, which is when the entire page has been removed, or “Changed content”, when the just an image has been removed from a page that still exists.

It’s important to note that when you are removing content from a page that still exists, Google will first purge the snippet and the cache for that page. Then the cache and snippet will be refreshed the next time the page is crawled. If you want, you can run a site query on the page and you will see the listing without a snippet and cache link.

For example, enter site:{enter page url here} in Google. You should see the snippet has been removed and the cache link is gone until Google recrawls the page.

Summary – Removing Images From Google That Are Caught In The Matrix
Having an image linger around Google Images when it has really been removed can be very frustrating. But as you can see, there are ways to remove those images from the search results (from third-party sites) by using the tools Google has provided. And once you submit your removals, it only takes a day or so for the images to be removed from the results. But remember, make sure the images have really been removed from the web. If not, the request will not be successful. 

GG

In October of 2019, Google announced a plan to gradually block mixed content over time. Mixed content is a common issue across sites where secure pages attempt to load insecure content. For example, loading an image file over http from an https page. There are security risks associated with that, so Chrome wants to eliminate that risk in the future (by blocking mixed content from loading).

Since it’s a common issue, Chrome announced a staged plan in October so site owners would have plenty of time to research and fix mixed content issues on their sites. Even though the blog post was published in October of 2019, I’m still seeing a lot of confusion about the topic when working with clients. In addition, I’m finding many companies don’t even know that Chrome has begun blocking some types of insecure content already. 

In this post, I’ll first cover the timeline that Google mapped out for Chrome’s handling of mixed content. Then I’ll cover how the problem could break pages visually, I’ll cover the rendering impact, I’ll provide examples of what blocking looks like, and then I’ll end with some final tips.

Chrome’s Mixed Content Timeline:
In Google’s blog post about blocking mixed content over time, they provided a staged rollout. The plan was to gradually block mixed content versus simply flipping a switch and having pages break.

• The first change was in Chrome 79, where Chrome started providing a setting where users could unblock mixed content on specific sites. The setting applies to mixed scripts, iframes, and other types of content that Chrome blocks by default.
• In Chrome 80, which is the current version of Chrome as I write this article, Chrome will attempt to auto-upgrade audio and video resources to https (if possible). If the resources cannot be auto-upgraded, then Chrome will block the resources from loading. This is completed automatically by Chrome for sites trying to load audio or video resources over http from an https page.
• In addition, Chrome 80 will allow mixed images to load, but that will cause a “Not secure” label to be displayed in the browser. So, loading images over http will still allow the images to appear on the page (as of now), but the url will have a “Not secure” label in the browser window.
• Then in Chrome 81, which was supposed to be released in February 2020 but hasn’t rolled out, Chrome will attempt to auto-upgrade mixed images to https. If they fail to load over https, then Chrome will block those images completely (they won’t load on the page).
• Regarding the rollout of Chrome 81, the Chrome team announced that based on the global pandemic, Chrome 81 will not be released yet. Therefore, the final stage in the gradual rollout of blocking mixed content is not live yet. But, you can test it out via the Canary build of Chrome (which I’ll cover soon). As of today (Chrome 80), the stable version of Chrome is not auto-upgrading or blocking mixed images yet. It’s just showing a “Not secure” label for mixed images. But Chrome 80 is auto-upgrading audio and video resources to https and blocking them if they won’t load over https.

Insecure Images, A Common Mixed Content Issue
I’m sure some site owners and SEOs reading this post are confused about what mixed content is and how it looks. First, if you are running your pages over https, then all resources should be loaded over https. If you try to load resources over http, then that’s where mixed content warnings arise. Again, it’s a common issue that’s impacting many sites across the web.

As a simple example, here is a secure page (https) that is loading three images over http (insecure) in the stable version of Chrome (v80). Notice the “Not secure” label in Chrome versus the secure padlock.

When using Chrome Dev Tools and checking the security tab, you can view the resources that were loaded over http. You typically need to refresh the page to see those resources.

Since we are in stage three of the rollout (Chrome 80), the images will be allowed to load, but Chrome will display a “Not-secure” label in the browser window. To clarify, the images will still show up on the page and you will not run into any rendering issues (yet).  

It’s worth noting that audio and video will be auto-upgraded to https in Chrome 80. If they can’t be loaded over https, then the content will be blocked entirely. I’m focusing on images in this post, but that’s important to know if you are using audio and video on your pages.

Chrome Canary – The Ability To See Into Chrome’s Future
The Chrome Canary build is a version of Chrome that’s updated nightly with the latest functionality. It’s a great way to test your site and functionality for future versions of Chrome. There are many times I’m activating functionality in Canary that’s not yet in the stable version of Chrome to see how that will work when it finally does roll out. 

Since I know that Chrome 81 is nearing release, I was able to test how Chrome would handle mixed images. Remember, the stable version of Chrome simply adds a “Not secure” label in the browser window, but Chrome 81 will auto-upgrade those mixed images if possible. And if the images cannot load over https, then they will be blocked entirely. That means they won’t load on the page. And that also means it can impact what Google sees when it renders your pages.

As a quick example, I set up a page that loads an image via http and that image cannot be auto-upgraded to https. As you can see below, the image is blocked entirely from Chrome (and doesn’t show up on the page). The page actually shows up as secure in Canary (the “Not secure” label has been removed), but the page simply displays a missing image icon. That’s not good if it’s a critical piece of content for users.

Image blocked from loading:

The page is now secure, but the image is blocked:

The resource failed to load since it can’t be auto-upgraded:

Evergreen Googlebot, Broken Renders, and Ranking Impact
OK, so now we know that mixed images will not load in Chrome 81 if those images cannot be auto-upgraded to https. And we saw how that looks in the browser with broken image icons showing up on the page. That’s not good for users at all, but what about Google?

Google’s John Mueller has explained that since Google uses an evergreen Googlebot now for rendering, it will be using the latest version of Chrome. That means it will be using Chrome 81 once that rolls out. Again, that hasn’t rolled out yet due to the global pandemic, but it will at some point soon.

So if Googlebot will be using Chrome 81 to render your content, and we already know that Chrome 81 will block mixed images, then that’s exactly how Google will see it. So key images will be missing from your renders if those images cannot be loaded over https.

In addition, from a ranking perspective, John explained that the blocking of images shouldn’t impact rankings based on Google’s https ranking signal. That’s good to know, but he also explained that if the pages cannot render completely in a browser, then Google probably won’t be able to render those parts either. And he clearly recommended fixing that issue.

Here is a link and screenshot to a reddit thread where John explained this:

Wrapping Up and Final Tips:
Before I end this post, I wanted to provide a number of final tips and suggestions based on researching this topic. Remember, site owners still have time before Chrome 81 rolls out to address mixed content issues. Based on what I provided in this post, it would be smart to rectify those issues now before Chrome 81 rolls out. Here are some final tips:

• Crawl your site and surface all mixed content issues. My three favorite crawling tools are DeepCrawl, Screaming Frog, and Sitebulb. All three provide specific reporting for mixed content. Note, I’m on the customer advisory board for DeepCrawl. It has been one of my favorite enterprise crawling tools since 2013.
• Understand that Chrome 81 has NOT rolled out yet and Google has paused updates due to the global pandemic. Chrome 80 is the stable version of Chrome now and it does display a “Not secure” label for pages with mixed content problems. Also, Chrome 81 will roll out relatively soon and will completely block mixed images that don’t load over https (when auto-upgraded).
• Chrome 80 currently attempts to auto-upgrade audio and video to https. And it those resources fail to load over https, Chrome will block them from loading.
• Mixed content problems can impact your pages visibly for users, and for Google rendering your pages. Remember, Google now uses an Evergreen Googlebot, which utilizes the latest version of Chrome to render your pages. That means Googlebot will be using Chrome 81 to render pages once it rolls out. As Google’s John Mueller explained, you definitely want to fix mixed content issues that impact rendering.
• John Mueller also explained that this shouldn’t impact rankings based on Google’s https ranking signal. That’s good news, but again, it can impact what users see on your pages and what Google is able to render.
• You can use Chrome Canary to test your pages now to see how mixed content will impact your site once Chrome 81 rolls out. It’s a great way to test Chrome’s latest and greatest functionality that hasn’t rolled out to the stable version of Chrome yet.

Address Mixed Content Issues and Avoid Broken Pages and Partial Renders
In this post, I covered Chrome’s plan to gradually block mixed content. The final stage of the rollout will be completed when Chrome 81 is released as the stable version of Chrome. But as I covered in my post, the release of Chrome 81 has been delayed due to the global pandemic. Therefore, you still have time to fix mixed image problems before Chrome blocks them from loading (if they can’t be auto-upgraded to https). And remember, audio and video resources are already being blocked if they can’t be auto-upgraded.

I recommend thoroughly testing your site to ensure you surface, and then fix, mixed content problems. Then you can rest assured that both users and Googlebot can load and render all of your resources, including images, video, and audio.

GG

For many site owners and SEOs, SafeSearch can be a confusing topic. For example, understanding how SafeSearch works, what filtering looks like in action, and how it can impact traffic from Google organic search. That’s especially the case for sites that walk a fine line between providing non-explicit and explicit content (at least according to Google’s algorithms).  

I’ve worked on several cases recently where SafeSearch came into play. Site content was being filtered for users with SafeSearch active, which was impacting the visibility of content in the SERPs and subsequent traffic to the site.

But these weren’t porn sites being filtered… far from it actually. Instead, the sites are publishers that write about a range of topics within their niche. And sometimes those articles provide content and images that trip the SafeSearch filter. When that happens, those urls and images are filtered out of the search results yielding lower traffic levels from Google.

And to clarify, filtering applies to images, videos, and websites, so it’s not just about filtering in the standard organic results. It impacts your media as well.

This is why it’s a smart idea for publishers to become as knowledgeable as possible about Google’s SafeSearch feature, how it works, how to test if you’re being actively filtered, and how to test new content to future-proof your site.

That’s because if you trip the filter, traffic could drop to various degrees depending on how the filter is applied. For example, is SafeSearch just impacting certain areas of the site or the entire site? It depends on your setup, your content, and how far your content crosses the line.

Also, while helping companies deal with SafeSearch filtering, I’ve received many questions about how to test content to see how close it is to tripping the SafeSearch filter. And if you do trip the filter, how do you know you are being filtered? And what about if you are incorrectly being filtered? Can you reach out to Google to let them know that’s happening?

These are all important questions and I’ll be covering a number of these topics in this post.

Images and Text, Not Just Explicit Photos
A lot of people don’t know this, but Matt Cutts was tasked with creating the first version of SafeSearch. He explained more about this during a recent interview with Barry Schwartz (at 12:08 in the video). In that interview, Matt explained that Google initially used text to understand what should be filtered. Since the first iteration of SafeSearch was in about 2000, Google didn’t have machine learning algorithms to help identify pornographic images. Therefore, it was mostly text-based.

SafeSearch is undoubtedly much more sophisticated now and Google has explained it does use machine learning to detect explicit content that should be filtered. More about that soon, but I wanted to make sure you understood that both text and images are taken into account. Also, there’s a SafeSearch team at Google that is focused on the feature. That’s also important to understand in case you run into trouble, like if your site is incorrectly being filtered.

An older Google help document I surfaced, which is now removed, explains that SafeSearch looks at “keywords, links, and images” to determine what should be filtered. So again, it’s not just images.

Tripping The SafeSearch Filter – What Can Happen?
When a site trips the SafeSearch filter, Google will filter some (or all) of your pages for users that have SafeSearch active (again, across images, video, and websites). It’s an option in your search preferences, so some people have to manually turn it on. For others, it might be turned on at a higher level, like a school administrator, IT department, or even a parent managing a child’s computer.

If this happens, then your pages won’t appear like they normally would for certain queries leading to your site. They will be filtered out. Poof, gone. There’s no communication from Google about this, like a message in GSC (at least that I know of). Instead, your pages will just be filtered in the SERPs.

As you can guess, some sites can experience lower traffic levels depending on their target demographic. For example, if your audience includes people that have SafeSearch turned on, then the filter can cause problems traffic-wise. If most users that visit the site don’t have SafeSearch active, then you might not even know you are being filtered. It’s tricky that way.

But let’s face it, “tricky” is a four-letter word in SEO. As a site owner or SEO, you definitely want to know if your content is being filtered by SafeSearch. You don’t want any surprises down the line, like ghostly traffic drops that are hard to figure out. That can be very frustrating. I’ll explain how to check for SafeSearch filtering soon, but first a note about site structure and adult metadata.

How Site Structure Can Help Google Focus Its SafeSearch Filtering
Google has explained that you can help its algorithms understand which sections contain adult content by using a specific url structure for organizing content (see the section about optimizing for SafeSearch at the bottom of that page). For example, placing all adult content in a specific directory.

If you do that, then Google’s algorithms can determine that the entire site shouldn’t be filtered, but just the specific directory. That can save you down the line, so I highly recommend trying to organize your content that way if you need to publish adult content for some reason (or content that Google believes is explicit).

Now, you might be wondering what exactly constitutes “adult content”. That’s a tricky one… since it’s determined algorithmically. I’ll cover ways to understand how your content is being viewed by SafeSearch later in this post.

Adult Meta Tags
Google also explains that the best way to let them know that adult content is on your page is to use adult metadata. They say it’s the “strongest signal” you can provide about this. There are two meta tags you can use in your code to accomplish this (you just need to include one, but you have a choice).

How To Check For SafeSearch Filtering – Tripping The Filter
Below, I’ll cover several ways to check to see if your content is actively being filtered by SafeSearch. You’ll be checking after-the-fact, meaning you are already being filtered. After I cover these methods, I’ll explain how to conduct some preventative work to make sure you stay out of the danger zone. i.e. Testing content you want to publish to see how Google’s SafeSearch sees the content.

Before we begin, I find it’s easier to check for SafeSearch filtering with two browsers open. One will have SafeSearch on and the other off. And if you have dual monitors, it’s great to have one browser up on each display.

1. Perform a site command with SafeSearch active
First, fire up the browser with SafeSearch on and perform some site commands (including by directory). In extreme cases, you will see 0 results returned when your entire site is flagged and filtered.

For sites not completely filtered, I’ve found site queries to be a little sketchy. Sometimes they show a site being partially filtered and sometimes they don’t… So use this as a quick way to check for filtering, but don’t 100% rely on it. Again, for sites being completely filtered by SafeSearch, this can be helpful. For partial filtering, this process can be unreliable.

2. Identify at-risk queries and perform actual searches
The best way to check for SafeSearch filtering is to start searching using the two browser-setup I mentioned earlier. First, go to GSC and export a bunch of queries leading to your site. Find ones that would be considered risky from a SafeSearch perspective (either based on the query itself or the content you have at the destination landing pages). And then start searching.

Enter a query in the browser with SafeSearch off, check your rankings, and then perform the same search in the browser with SafeSearch on. You might be surprised with what you find. You might see major gaps in the SERPs where your pages used to rank. If that’s the case, yep, you’ve tripped the filter.

I just did this for a client and found many queries that yielded SafeSearch filtering for them. And the filtering was focused on one specific directory (which made complete sense considering how they have the site structured).

Remember what I said earlier about the importance of url structure for SafeSearch? Well, they luckily house all risky content in one directory. That’s the good news. The bad news is that there’s a lot of non-explicit content there as well… So, certain pages are being filtered by SafeSearch, but at least it’s not the entire site being filtered.

Repeat for more queries and identify which queries and landing pages are being filtered. By analyzing more of this data, you can start to get a feel for what crosses the line content-wise. That’s a good segue to the next section of this post… how to catch problematic content before it gets filtered.

How far is too far?… Enter Google’s Vision API
Up to this point, I’ve covered how to check if you’re actively being filtered, but what about performing some preventative work BEFORE you get filtered? This is a natural question for any company that has gotten caught in the filter. They normally want to future-proof their site and they don’t want Google categorizing the site as adult (or a site that houses some adult content).

Well, Google has you partially covered, pun intended. :) Enter Google’s Vision API, which is pretty amazing. It uses machine learning to automatically identify and categorize images. You can read more about the Vision API on the site, but I’ll stick to how we can use it based on this post.

One of the features of the Vision API is that it can be used to detect explicit content via SafeSearch. It can identify adult content, violence, and more. It also uses OCR to detect text in the image, so it’s not purely about the images in the photo.

Also, if you have development resources, then you can tap into the API at scale to check your images using SafeSearch. If you don’t have development resources, and you’re not checking a lot of images on a regular basis, then you can test specific images right on the site. There’s an option to try the API for single images.

After dragging an image to the tool, or selecting one from your computer, Google’s Vision API will analyze that photo and return a boatload of information, including sections for faces, objects, labels, entities, webpages that contain the image, text, properties, and… SafeSearch.

Yes, there’s a dedicated section for SafeSearch that provides the likeliness that the image is adult, spoof, medical, violence, or racy. It’s fascinating.

When testing various images using the API, you can start to get a feel for what crosses the line. Here are some examples of what the API returns for SafeSearch. The first returned the likelihood of being “racy”, but not really “adult”, while the second crossed the line and returned “very likely” for both “adult” and “racy”.

Note, although you’ll receive some great information from the API, it’s hard to tell exactly what will trip the SafeSearch filter. That said, this sure gives you a stronger view of how SafeSearch works. If you see “Very Likely” for both Adult and Racy, then that’s clearly an image you want to rethink (if you don’t want to trip SafeSearch). Also, you don’t want Google to begin to classify your site, or parts of your site, as having adult content.

False Positives, Notifying Google That Your Site Is Incorrectly Being Flagged
Machine learning algorithms aren’t perfect and there are times sites are incorrectly flagged as having adult content. If you experience this situation, then you should let Google know about it. In the past there was a form you could fill out to let Google know your site was incorrectly being flagged by SafeSearch.

Unfortunately, Google removed that form and now drives site owners to the webmaster forums to make their case. I’m not a big fan of that approach since site owners often don’t want to announce to the world that their site is being flagged by SafeSearch (especially if they don’t focus on adult content…)

So, the good news is that you can post in the forums and hopefully get your information in front of a Googler on the SafeSearch team. The bad news is that you have to tell the world about it, since the post is going to be public.

Feature Request: SafeSearch Report in Google Search Console Wanted!
After helping some companies with this situation, I think it would be great to have a notification in GSC or some type of report that lets site owners know if their content is being flagged by SafeSearch. And maybe have a “request review” button there in case the site, or sections of the site, are incorrectly being flagged. Here is what that can look like (hint, hint GSC team). :)

Closing Tips: SafeSearch, Tripping The Algo, and Future-proofing your site
As I explained earlier, it’s important to become as familiar as possible with SafeSearch if you provide content that could be classified as explicit (like adult content). Using the methods and tools listed in this post can help you determine if you are currently being filtered, and to understand if you might be filtered in the future. Below, I’ll cover some final tips and recommendations:

• Understand your current situation fully. If you think SafeSearch might be at play with your own site, perform thorough testing to see if you are being filtered. Then form a plan of attack if you are. Use the methods I listed earlier to test queries with SafeSearch off, and then on. Again, you might be surprised with what you find.
• If you provide adult content (or any type of content that might be deemed explicit), then start conversations with your marketing and dev teams about site structure. Remember, Google has explained that placing all adult content in a specific directory can help its algorithms understand where explicit content resides on your site (and then SafeSearch can be as granular as possible).
• Use adult meta tags to provide self-marked pages that contain explicit content. Google explained this is the strongest signal you can send to them that your pages contain adult content.
• Identification-wise, SafeSearch takes both images and text into account. It’s not just the image content.
• If you are being filtered, then that filtering can happen for webpages, video, and images. It’s not just about filtering in the standard organic search results.
• Educate your editorial staff about SafeSearch and show them how to test images via Google’s Vision API. This can help protect your site down the line by having employees conduct preventative checks BEFORE that content is published.
• And if you believe your site is being incorrectly flagged by SafeSearch, you unfortunately can’t submit a form to tell Google like in the past. You must go got the webmaster forums to provide the details. That can hopefully get in front of a Googler on the SafeSearch team, but there are no guarantees.

Summary – Try To Be Safe With SafeSearch
I hope this post helped you gain a better understanding of Google’s SafeSearch feature, how to test your own site, and then how to conduct preventative checks. Don’t let some ghostly drop in traffic create a confusing situation for your company. Know when you’re being filtered and then form a plan for handling that situation. Good luck and safe searching :)

GG