Search Console, sitemaps, SafeSearch labels, watch pages: what a new adult site needs to get indexed, per Google's own docs, and the five things that block it.
- Published
- By the Jimp team
- Also in
- Français
A new adult site gets indexed the same way as any other site, with two differences that are specific to adult. Google has to be able to read it as explicit and file it under SafeSearch, and it has to be able to reach the pages and the videos without hitting an age gate. Verify the domain in Search Console, submit one honest sitemap, give every video its own page with its own text, and expect weeks, not days. When a new site stays out of the index, the cause is almost always on the site, and it is almost always one of five things.
Everything below is from Google's own documentation, linked as we go. Nothing in it is a trick.
Search Console first, on the whole domain
Add the site to Search Console as a domain property, not a URL prefix. A domain property covers every subdomain and both protocols, so www, the bare domain and any cams. subdomain you add later all report in one place. It is verified with a DNS TXT record, and Google's help page is explicit on two points: it can take a day or two to be seen, and you leave the record in place after verification succeeds.
Do this before launch day, not after, so the first weeks are there to read as they happen. They are the weeks that tell you whether the launch worked.
One sitemap, with dates you can defend
A sitemap does not get pages indexed. It tells Google which addresses exist and when they changed, and Google decides the rest. Get the mechanics right and it is one less thing between you and the index.
The sitemap documentation gives the limits: 50,000 URLs or 50 MB uncompressed per file. A tube passes that sooner than people expect, so split by type (videos, categories, performers) under a sitemap index. Submit the index in the Sitemaps report, and add a Sitemap: line to robots.txt so every crawler finds it.
Two details matter more than they look. Google ignores priority and changefreq, so do not spend time on them. And it uses lastmod only when it is "consistently and verifiably" accurate. A tube that stamps today's date on every URL at every rebuild teaches Google to ignore its dates altogether. Put the date the page actually changed, or leave it out.
For the videos, add the video sitemap tags: a thumbnail, a title, a description, and either the file or the player URL. On an adult site, one tag is not optional in practice. video:family_friendly set to no tells Google the video is explicit; omit it and Google assumes the video can show with SafeSearch on.
SafeSearch is a label, not a penalty
This is the part that worries people and should not. SafeSearch filters explicit results for users who have it on. It does not remove your site from search. It sorts it, and an adult site that is sorted correctly is one Google shows to the people searching for it.
Google's guide for explicit sites asks for three things. Label explicit pages with <meta name="rating" content="adult"> (or the RTA label, either is fine). If a domain carries both explicit and non-explicit content, group the explicit part on its own subdomain or directory, or Google may treat the whole site as explicit. And let Googlebot in. Two lines of that page are worth reading twice. An age gate that blocks Googlebot can get the site classified as explicit automatically, which is the right label for a tube anyway, but also means Google never saw the pages. And if Google cannot fetch your video files, it "can't run automated protections" and may demote or filter those pages, which the page says "may significantly affect the ranking" of explicit pages.
For an embed tube, that last point is worth checking. The video file lives at the source, and whether Googlebot can fetch it is the source's setting, not yours. What you control is that your own pages, thumbnails and player markup are open to it.
If you ever need the reverse, a non-explicit site wrongly filtered, the troubleshooting page says to fix the cause first and then wait: reclassification can take two to three months, after which there is a review form.
Every video needs a page of its own
Google indexes a video when it finds it on a watch page, a page whose main content is that one video. A category grid with twenty embedded players is not a watch page for any of them. The video best practices say it plainly: one dedicated watch page per video, the player not hidden behind other elements, a thumbnail in a supported format and at least 60 by 30 pixels, and structured data with a name and a description unique to that video.
That last requirement is where tubes fail quietly. A feed gives every site the same title and description for the same video, and the page that repeats them is a duplicate of every other site's page. It gets crawled and not indexed, or indexed under someone else's canonical. Search Console's video indexing report lists the technical reasons a video was not indexed, from "Video isn't on a watch page" to "Thumbnail blocked by robots.txt"; it will not tell you the text was the problem. You have to know that yourself.
Reading the page indexing report
After two or three weeks, open the Page indexing report. Two statuses will hold most of a new tube's pages, and they do not mean the same thing.
"Discovered, currently not indexed" means Google knows the address and has not fetched it yet, typically because it expected the crawl to overload the site and rescheduled it. On a new domain this is the queue. It shrinks as the site earns crawl, and publishing faster makes it longer, not shorter.
"Crawled, currently not indexed" means Google read the page and decided not to keep it for now. Google's own note on it says there is no need to resubmit. This is the status to worry about in bulk, because it is a verdict on the page. On a tube, when thousands of video pages sit here, the usual reason is that they say what a hundred other sites say.
A third one appears when text is shared: "Duplicate, Google chose different canonical than user". Your page pointed at itself, Google decided another address was the better version and indexed that one instead. When that other address is on another domain, it is the same diagnosis as above.
The five things that block a new site
| What you see | The usual cause | The fix |
|---|---|---|
| Nothing indexed at all after weeks | A noindex left from the staging phase, on every page |
Remove it; check the page source and the HTTP headers, not the CMS setting |
| Pages "blocked by robots.txt", or indexed with no description | A Disallow too broad |
Allow the pages; robots.txt is "not a mechanism for keeping a web page out of Google", and a noindex only works on a page Google can crawl |
| Pages fetched as an age gate or a blank page | The age gate or a geo block also stops Googlebot | Let Googlebot through, as Google's explicit-content guide asks |
| Thousands of "Crawled, currently not indexed" | Pages that repeat a feed's text | Unique titles and descriptions, and fewer, better pages |
| A slow crawl that never speeds up | Far more pages published than the site can get read | Publish at a steady pace, and never all at once |
The fourth row has a name in Google's spam policies. Scaled content abuse covers "scraping feeds" to generate many pages, and thin affiliate pages are those where content is distributed "across a network of affiliates without providing additional value". A tube that serves the feed as it comes fits both descriptions.
How long it takes, and what not to do meanwhile
Google does not promise a timeline. Its URL Inspection help says indexing "typically takes only a day or so, but can take much longer", that requesting it does not guarantee it, and that there is a daily limit on requests. Its recrawl page puts crawling at "a few days to a few weeks" and says asking twice for the same URL does not make it faster.
So use "Request indexing" for the handful of pages that matter, the home page and the main categories, and let the sitemap carry the rest. Do not resubmit the sitemap every day. Do not publish ten thousand pages to "give Google more to find". A new domain gets a small crawl, and pages published past it wait in the Discovered queue while the site is judged on the ones that were read.
On a Jimp site the sitemap lists only the videos that are online, each with its real publishing date, and new videos arrive at a pace a young domain can get read; the scheduled publishing page shows the curve and the publishing and SEO page of the docs explains the reasoning. Whatever you build with, the checklist is the same. Domain property, one honest sitemap, the right label, Googlebot let in, a page per video with text of its own, and patience measured in weeks.
Keep reading
Tube SEOPicking a niche for a tube site that can actually rankNarrow enough to be the best result for something, deep enough to publish every day for years: the two tests a tube niche has to pass before you build on it.7 min readRead
Tube SEOA new site takes weeks to be found. Here is how Jimp does it in an hour.A fresh domain waits for a crawler nobody sent. What we changed so that every page a Jimp site publishes is named to the search engines, posted on its own channels and given a share card, within the hour, with the screens to prove it.5 min readRead
Build a site that does all of this by default.
Three minutes, no card, a real site with your niche and your codes.