Looks good to me.

I'm comfortable closing this task as resolved given that I've been getting search console requests from people following the process as documented and have been resolving them.

Hello Taavi,

I think ThisDot should be in the table here: https://www.mediawiki.org/wiki/Gerrit/Privilege_policy#Expedited_process_for_trusted_organisations

Just escalated to the folks talking to Google one more time.

Fixed, thank you.

The search console says this page is simply unknown to Google.

I have a patch ready if someone would like to review it.

Here is a summary of our discussions with Google (they proofread this summary):

Update: First Input Delay is going to be deprecated in favour of Interaction to Next Paint.

@Nicholas_Perry is the person talking to them.

Partnerships just told me they will reach out to Google soon. We'll post updates here.

I've requested partnerships to look into this too.

That bit you're seeing is called the "Site Name", as distinct from the page title. The idea behind it seems to be to tell you what site you're looking at (without needing to look at the URL itself, or relying on the page title to include the name of the site).

The important takeaway from this (as per our discussion) was this bit:

We met with Google to discuss this further. Google will provide more details on this soon, but the crux of the matter is that not all pages are guaranteed to be crawled, indexed, and served, as is stated on Search Central documentation.

@Seddon Could you please post an update here and link to relevant tickets?

Folks, here's a plan of action.

Seddon and I are meeting on Friday. We'll have a concrete action plan (or
the beginnings of one) to share on Monday.

We're meeting with them in the next couple of weeks to troubleshoot our scraping problems. Will report back once we learn more.

Manager here: I approve.

This has been reported to Google. We're waiting for them to get back.

@Jdlrobson Did the frontend standards group meeting come to a conclusion, or did it bring up any new insights not already shared in this ticket?

Thanks for all the inputs.

@elukey Do we have another idea on the table aside from asking a team of Android devs (3) to maintain a recommendations service?

This has been granted for a period of one year.

@Soda I need a gmail account to provide access to.

OK, having talked to some folks in the Enterprise org and other teams and having eliminated a few possible problems, the one I'm investigating now is the possibility that for some reason Google's bot is ratelimiting itself. I'll continue to post any findings here.

Thank you for the supporting links.

Here are some unindexed articles (confirmed from search console and from Google). I came upon them by simply hitting "Zufällige Seite" (Random Page) on de Wikisource and checking if the resulting page is indexed at all.

@Xover That's very useful to know.

@Soda Yeah Navboxes would indeed have helped.

@Krinkle Could you please answer the question I had above when you have a chance?

As far as I can tell, a lot of the pages that aren't appearing in the index are simply not linked to from within the Wiki. There are no sitemaps any more, and Special:Lonelypages is uncrawlable because there's a robots.txt rule blocking all Special: pages from being crawled.

I think we can close this task for now.

If the volunteer is given access to Search Console data, they will be able
to examine the following information:

• which queries lead to search results on Google that have Wikis in them
• which results get clicked on by users
• the total query volume that has search results from the Wikis
• Whether a given page from a Wiki property has been indexed or has

problems preventing it from being indexed

• a breakdown of the above information by device platform, country, and

date.

Manager approval if needed: approved

I've responded on the ticket with the volunteer. I'll handle it once they get the NDA and C-level approval out of the way.

Please assign this to me once C-level approval and NDA have been taken care of.

No strong opinions either way, but it seems to me that the examples that @pmiazga provides aren't all user types. "admin", "group:something", or "en_wiki:admin" are not really user types. They're memberships or privileges, which can grow and change as needed. Isn't there another way to represent those? I would imagine that a user type is something that's largely permanent, while privileges (through memberships) are expected to change.

Silly question: @Krinkle Given that robots.txt has a Disallow: /wiki/Special: rule, how do search engines read the LonelyPages or RecentChanges pages? As far as I can tell these pages aren't being indexed. Am I missing something?

Apologies for the ridiculous delay. I have Wikisource search console access now and am looking at it.

Manager approves.

WMF Staff who will need this on an ongoing basis. No expiry.

Perhaps @Dbrant knows? I remember Jdlrobson mentioning that they did some work together on this.

Rather than speculate on this one feature in isolation, I recommend letting @ovasileva decide and prioritize based on what else needs doing. She likely to have a more holistic view and more insights from the community.

Just had a conversation with @Catrope . I'm comfortable owning the risk and understand what that entails.

That is not the case. Quoting from T326816 (please read for details):

Please note that any changes to this extension might first need to be
discussed in T326956.

I've mostly focused on search performance and stats for the Wikipedias and haven't had a chance to set up and build an understanding of where we are with Wikisource yet. That's why I don't have an immediate answer for this problem.

The vendor replied with numbers over the last two days. Here are some numbers that might help decide on a strategy. There is a new dump of IPs every day. Between the last two successive dumps (today and yesterday) there is:

• 10-12% daily change
• 1.7M New entries
• 2M Aged off entries (i.e. dropped/removed)

Thanks for replying, @Ladsgroup

Are DBA and SRE folks aware that this entire database will essentially be wiped every one or two days and recreated from a dump? Does that complicate things in any way?

Apologies, I don't have access to wikisource. @mpopov does probably.

Trying to summarize the discussion above, please point out where incorrect:

Also granted access to ptwiki and hiwiki (desktop + mobile) as requested by @ovasileva

English has also been added. Thanks for the action, @jcrespo. Noted, will notify the on-duty next time. Modified the wiki accordingly.

I've granted access. @jcrespo could you please add the expiration date to maint-announce and close the ticket?

Access has now been revoked.

Manager is OOO.
Skip-level Manager here, approved (if needed).

@phuedx Was the exclusion of is_bot intentional?

Just checked, these are safe to delete.

Option 1: "Inline after the lead section" has some advantages.

1. It resembles the previous state and allows the menu to go back to its previous narrower form (now that it doesn't have to match widths with the ToC which needs to be wider). This will probably leave people that like narrow windows largely unaffected.
2. Yes, in that case, there's no floating ToC any more, but then if the window is that narrow, there's no room for one anyway.

I've given the above-mentioned e-mail address access to the two English
Wikipedia domains (en.wikipedia.org and en.m.wikpedia.org).

@jcrespo I've been involved in this discussion so I know what's going on here. I've updated the ticket to reflect what they need. I can take care of providing access; how do I put an entry in the maint-announce calendar to revoke access on the expiry date?

That's _very_ interesting. Thanks for doing this! Would it make sense to just test this theory a bit more?