Change "shorturl" in FileRepo to something searchengine-friendly
Open, Needs TriagePublic
Actions

Assigned To

None

Authored By

	Krinkle
	Jun 5 2026, 6:32 PM

Project Tags

Referenced Files

None

Subscribers

Description

Background

While pages and revisions have been cleanly separated in our database schema since 2004 with a stable page_id that is used throughout MediaWiki.

File uploads, on the other hand, did not have a stable primary key in that way. I proposed fixing this in 2011 (T589) and after 25 years, are are now in the midst of those schema changes rolling out this and last quarter years (T28741). However, these new file IDs are yet to be adopted anywhere.

In any case, this is why files are generally identified by their current filename (i.e. "Example.jpg"). This is chosen during upload, and is then controlled via the File description wikipage (i.e. [[File:Example.jpg]]) which, like any wiki page, can be renamed. More about issues with that in T20493: RFC: Unify the various deletion systems.

Given that file names may be upto 250 characters in length, and the fact that they can change, we introduced the File::getDescriptionShortUrl method in 2015 for use by MediaViewer. Specifically, for use in the recommended "credit" when downloading an image to then re-use in an offline publication, or on your own website (T20493). The method uses an "ugly" /w/index.php URL with a curid parameter (pointing to the File description's page ID).

Credit example from this photo:

By Dominicus Johannes Bergsma. - Own work, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=162667099

Alternative without this feature:

By Dominicus Johannes Bergsma. - Own work, CC BY-SA 4.0, https://commons.wikimedia.org/wiki/File:Euphorbia_griffithii_(wolfsmelk)_22-03-2025_(d.j.b.)_01.jpg

Source code: Codesearch

Problem

This URL is statically prevented from crawling by search engines because it uses /w/index.php, and that is categorically excluded from crawling without even hitting the page in question.

This is a good thing, as we'd otherwise get a ton of expensive, uncachable traffic on our backends just to tell the crawler the URL shouldn't be indexed (e.g. endless pagination on special pages, action=history, oldid permalinks from the revision history, action=edit, and lots and lots more).

This URL does not redirect to the canonical page.

Even if we hacked around the robots.txt classification, it's still expensive to serve, likely uncached, and doesn't redirect. MediaWiki (correctly) serves it with a noindex instruction, because it's a non-canonical URL.

<meta name="robots" content="noindex,follow,max-image-preview:standard">
…
<link rel="canonical" href="https://commons.wikimedia.org/wiki/File:Euphorbia_griffithii_(wolfsmelk)_22-03-2025_(d.j.b.)_01.jpg">

These short URLs are (likely) negatively affect page rank in search engines

Incoming links to these media files (both from our own webpages, but also from the web at large) should boost the ranking of the Commons page in question, and give it additional relevance based on the link's context via the pagerank link graph. However, this is likely short-circuited due to the short URLs being non-indexable, and thus preventing search engines like Google from crawling these.

Proposal A

Change the Special:Redirect/page/:page_id destination to use the canonical URL for the corresponding title (instead of /w/index.php?curid=). This currently suffers from the same issue described above, wasting crawler resources on a redirect only to end up un-crawlable and affecting SEO for the same reason. I would additionally suggest introducing Special:Page as alias for this, the same way that we have Special:Permalink for Special:Redirect/revision, and Special:Diff.

Swap the implementation from /w/index.php?curid= to /wiki/Special:Page

By Dominicus Johannes Bergsma. - Own work, CC BY-SA 4.0, https://commons.wikimedia.org/wiki/File:Euphorbia_griffithii_(wolfsmelk)_22-03-2025_(d.j.b.)_01.jpg

Proposal A+B

We can optionally go a step further in WMF production and additionally let the WikibaseMediaInfo extension make these URLs even nicer: https://commons.wikimedia.org/entity/M162667099

This is from the "Concept URI" in the sidebar. (Yes, that is indeed the same page ID. See also WBMI/MediaInfoHandler and WBMI/Hooks.)

Status quo

By Dominicus Johannes Bergsma. - Own work, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=162667099

Proposal A

By Dominicus Johannes Bergsma. - Own work, CC BY-SA 4.0, https://commons.wikimedia.org/wiki/Special:Page/162667099

Proposal A+B

By Dominicus Johannes Bergsma. - Own work, CC BY-SA 4.0, https://commons.wikimedia.org/entity/M162667099

Related Objects

Mentioned Here: T425897: Future of filearchive table
T426848: Local file pages are getting indexed by Google (duplicate content?)
T589: RFC: image and oldimage tables
T20493: RFC: Unify the various deletion systems
T28741: Migrate file tables to a modern layout (image/oldimage; file/filerevision; add primary keys)

Event Timeline

Krinkle created this task.Jun 5 2026, 6:32 PM

Restricted Application added a subscriber: • Aklapper. · View Herald TranscriptJun 5 2026, 6:32 PM

Krinkle updated the task description. (Show Details)Jun 5 2026, 6:33 PM

Maintenance_bot added a project: Commons.Jun 5 2026, 7:30 PM

Page IDs are stable over delete/restore and page moves. Is the same true of mediainfo entity IDs?

In T428296#11990773, @Tgr wrote:

Page IDs are stable over delete/restore and page moves. Is the same true of mediainfo entity IDs?

Yes. Unlike Q-ids on Wikidata (which are separately assigned), M-ids on Commons are merely a virtual proxy to MediaWiki page IDs.

Example from the task description:

https://commons.wikimedia.org/w/index.php?curid=162667099
https://commons.wikimedia.org/entity/M162667099

Note how they're the same number.

MediaWiki file IDs are generally stable as well, although these aren't in public use yet. The new file table, while inspired by the old/cur->page/revision change from 2004, actually goes a step further toward T20493/T425897 and also features a file_deleted field. This means, unlike the page table, the file table can represent deleted files. For example:

(commonswiki)> SELECT * FROM file WHERE file_name="RELX_LOGO.png" LIMIT 1;
+-----------+---------------+-------------+-----------+--------------+
| file_id   | file_name     | file_latest | file_type | file_deleted |
+-----------+---------------+-------------+-----------+--------------+
| 134256635 | RELX_LOGO.png |           0 |         5 |            1 |

The one case where a file ID is lost, is when renaming a public file to the name of an archived file. In that case, the placeholder for the archived file is removed. This is similar a page merge for revisions. Except, there afaik we do this lazily, preserved in the archive and lost upon restoration/merging into an existant page, which has a chance of being re-used if by the time you restore it, the overlapping file has been re-renamed or deleted. We may want to consider something similar in T425897/T20493 before/if we start using these publicly.

Maryana subscribed.Thu, Jun 25, 6:11 PM

JTweed-WMF edited projects, added: MediaWiki-Media-Platform-Team; removed: MediaWiki-Core-Platform-Team.Mon, Jul 6, 2:58 PM

Change "shorturl" in FileRepo to something searchengine-friendlyOpen, Needs TriagePublicActions