维基百科:互助客栈/其他/存档/2026年3月 - 维基百科，自由的百科全书

本頁是以往討論的存檔。請勿編輯本頁。若您想發起新討論或重啟現有討論，請在當前討論頁提出。

本主題或以下段落文字，已移動至Wikipedia talk:失效链接。执行者：Jimmy-bot（留言） 2026年3月2日 (一) 08:14 (UTC)。

本主題或以下段落文字，已移動至Wikipedia talk:維基百科標誌。执行者：Jimmy-bot（留言） 2026年3月15日 (日) 16:14 (UTC)。

快速、大量進行這兩件事的狀況，幾乎每隔數月就會發生。前者常由於編者不清楚或未落實Template:Notability中「致貼上本模板的編者：請搜尋一下條目的標題（來源搜尋："Notability" — 網頁、新聞、書籍、學術、圖像），以檢查網路上是否不存在該主題的可靠來源」說明，像是收錄標準提報中、由同位編者於一分鐘內做出的數次提報，User talk:Louischen88888#2025年11月中每天提報十幾筆的行為；後者則常源自編者對特定類型頁面的想法、或者對方針指引的解讀，像是Wikipedia:頁面存廢討論/記錄/2026/03/05中的數十個交流道重定向提刪，需要花費大量的社群人力去處理。有時部分破壞者像Wikipedia:持续出没的破坏者/User:离心力青蛙更是會透過這些途徑破壞，因此有防堵必要。

我的初步想法如下：

1. 將這兩種行為的間隔限制為5分鐘一次或更久，每人每天上限10筆，避免熱血提刪或破壞。
2. 若有機制可加強新頁面巡查者培訓、強制懸掛收錄標準模板者搜尋來源更佳。
3. 回退員、管理員處理大量違規、破壞頁面不在此限。

邀請User:日期20220626、User:银色雪莉參與討論。--迴廊彼端（留言） 2026年3月7日 (六) 06:36 (UTC)

技術上可以實現嗎？其實5分鐘一次或者10筆都算多的了。--日期20220626（留言） 2026年3月7日 (六) 06:46 (UTC)

目前已有过滤器286、345分别阻止新用户发起存废讨论及使用{{Notability}}了（所以离心力青蛙现在会通过讨论页请其他编者关注并提删）。我猜用过滤器可以基于它们实现这种频率限制。不过我在想“解决大量提删的人”会否比确定恰当的硬性限制更容易--Srapoj（留言） 2026年3月7日 (六) 07:57 (UTC)

其实设置简单的数量限制对真心想WP:POINT的人不会有多大效果。LTA大都是有某方面毅力的人，此外也有人大量提删甚至都不用Twinkle，也能坚持给每个页面手动完成列入讨论、挂模板、发讨论页提醒的三个步骤。真如此设限别人也可卡着上限慢慢来（结果令相似理由的提删分散于多日）。

本人倒是从WP:QPQ联想出一种机制，即提删需要扣除social credit，提删通过才能获得云云--Srapoj（留言） 2026年3月7日 (六) 09:59 (UTC)

我以前嘲諷過別人的提刪率問題，有些人提刪成功的概率也太低了。--日期20220626（留言） 2026年3月7日 (六) 10:02 (UTC)

我贊成對於每日懸掛收錄標準、提刪的頻率和數量加以限制（可以是硬性限制，也可是針對大量提删的維基人）。--Wolfch (留言) 2026年3月7日 (六) 08:04 (UTC)

我的意见可能跟Srapoj阁下差不多，对于执着或者片面理解的人不会有什么效果，对于懂的人可能又是一个不必要的限制。我只能说我不反对限制时间间隔，不过不知道技术上是否能做到这样。--银色雪莉（留言） 2026年3月7日 (六) 14:09 (UTC)

我不赞成频次硬限制，尤其是5分钟一次这么久，太耽误某些批量操作的节奏。软限制不反对，包括被机器人警告/人工提醒，每小时或每日的总次数，但上限要多一些，例如10次/小时、30次/日。不反对按过往提删频次等限制，但计分可能过于复杂。我觉得允许雪球回退（或快速关闭？）和强制冷静可以考虑。--YFdyh000（留言） 2026年3月7日 (六) 15:46 (UTC)

間隔跟次數限制主要就是想逼退熱血提報／提刪者，特別是根本沒照Template:Notability說明先查資料就一股腦亂掛的人，遇到堅持WP:POINT者至少仍可分散社群每日工作量。大量提報／提删的人很難解決，各位可以參考User talk:Louischen88888跟這幾天大量的交通條目提刪，沒幾個月就會重複發生我真心覺得累。--迴廊彼端（留言） 2026年3月7日 (六) 16:21 (UTC)

(－)反对，因噎废食，这个噎还是自己吃东西不嚼弄出来的。->>Vocal&Guitar->>_留言 2026年3月9日 (一) 00:26 (UTC)

不認為需要設限，畢竟社群一般討論積壓本身不是危害，祇要能夠按部就班清理即可。朝三暮四沒有意義。至遊戲規則者，社群亦當另有處置。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年3月9日 (一) 20:00 (UTC)

本主題或以下段落文字，已移動至Wikipedia talk:25周年。执行者：Jimmy-bot（留言） 2026年3月24日 (二) 08:14 (UTC)。

本主題或以下段落文字，已移動至Wikipedia:互助客栈/技术。执行者：12З4567（留言） 2026年3月19日 (四) 03:00 (UTC)。移动理由：技术问题，转交技术区

此問題是因為「是否應對懸掛收錄標準、提刪的每日數量、頻率予以限制？」所引發的想法。若短時間提刪大量條目，或短時間對大量條目掛收錄標準模板是不太合理的。那麼，短時間、密集的創建條目是否合理呢？

此情形下產生的條目多半是小小作品、小作品或初級條目，有基本篇幅，但內容不多。（若可以短時間頻繁密集的產生大量內容的條目，那就有可能是LLM產生的了，不過那是另一個議題，我目前不太想碰）。我之前聽到有維基人創建這類條目，期望「有緣人」繼續擴充，不過，屮文維基百科的「有緣人」沒有這麼多。

我還沒針對此議題想好具體規範的標準（例如「每人每天不得創建超過100個條目」之類的），只是提出想法，拋磚引玉，歡迎大家提供意見。若大家認為我多慮了，也可以提出。謝謝大家。--Wolfch (留言) 2026年3月7日 (六) 08:20 (UTC)

不过现在真的有人一天创建一百个小作品、或小小作品以上吗--Luoniya（留言） 2026年3月7日 (六) 08:31 (UTC)

「一天創建100個條目」只是舉例說明而已，不是我實際觀察到的現象。--Wolfch (留言) 2026年3月7日 (六) 08:34 (UTC)

我其实主要是觉得，现在本站，连有闲心大量建立小小作品的人都已经很少见了。--Luoniya（留言） 2026年3月7日 (六) 08:38 (UTC)

但剛好超過小小作品標準的新條目倒是不少... 駭客呼吸焉—☎️— 2026年3月7日 (六) 10:03 (UTC)

批量一天建立100個小小作品沒有，但批量一天建立100個小作品多年前就已經開始有了。隨便看一下巡查都會知道--某人✉ 2026年3月13日 (五) 14:57 (UTC)

「每人每天不得創建超過100個條目」，那我要@Dawson783：了。--日期20220626（留言） 2026年3月7日 (六) 10:04 (UTC)

還有個問題，那看提刪和創建條目到底算不算是貢獻，如果大量提刪和大量創建條目都無害，那可以放著不管，如果大量提刪有害而大量創建條目無害或者大量提刪無害而大量建條目有害，那就不能一視同仁了。--日期20220626（留言） 2026年3月7日 (六) 10:06 (UTC)

我是覺得大量提刪和大量創建條目都是有害的。--Wolfch (留言) 2026年3月7日 (六) 10:14 (UTC)

🤔理想狀況是能做到大量提刪精確符合刪除條件的條目或大量建立找不到提刪理由的條目，不過應該是後者更容易做到。--日期20220626（留言） 2026年3月7日 (六) 10:19 (UTC)

我认为两者都不应以单纯数量评定，如果说创建过多小作品就被认为有害，那不如禁止创建小作品，而非限制创建数量。对提删则是，判断其是否在游戏规则，也并非着重在数量--Luoniya（留言） 2026年3月7日 (六) 10:19 (UTC)

禁止創建小作品反而無益，這不就是人為抑制中維增加新的知識了。--日期20220626（留言） 2026年3月7日 (六) 10:22 (UTC)

所以我认为以现在限制其创建数量的理由来看，不如禁止创建小条目，两者并无本质区别，而这明显是无益的，故此反对限制创建数量。

当然上面说的小条目显然是不会被删的前提下--Luoniya（留言） 2026年3月7日 (六) 10:24 (UTC)

我覺得應當提高小小作品->小作品的門檻而非禁止小作品 駭客呼吸焉—☎️— 2026年3月7日 (六) 10:25 (UTC)

這個以前討論過幾回，沒成功。--日期20220626（留言） 2026年3月7日 (六) 10:28 (UTC)

現在有了草稿化應該更不會成功 駭客呼吸焉—☎️— 2026年3月7日 (六) 10:29 (UTC)

還是請大家回到「短期內大量創建小小作品/小作品/剛好超過小作品規模的作品好不好？是否有需要限制」來討論吧，謝謝大家。--Wolfch (留言) 2026年3月7日 (六) 10:11 (UTC)

理解提案人憂慮，但合格內容不應限制。至屢次濫建問題內容且不聽勸告者，本站另有規定處置。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年3月7日 (六) 10:46 (UTC)

一个老问题：“100（或者随便多少）这个数字是如何来的？一拍脑袋想出来的吗？”再者，本站人手是否已经少到无法由人类判断最近更改是否出现异常用户了呢？如果只是出于对大规模编辑超出控制的顾虑，我觉得不必如此。——暁月凛奈 (留言) 2026年3月7日 (六) 11:57 (UTC)

过往应该有过类似讨论。我认为批量创建（和修改）应该是批准制度，按修改规模和讨论进展决定讨论和公示期限。是否要一致同意则不确定。热血创建大量条目而无维护改进在过往有多次，劝解没什么用。单纯限制频次对每日创建到上限没有阻拦作用，限制字数篇幅也拦不住凑字而低质。--YFdyh000（留言） 2026年3月7日 (六) 15:50 (UTC)

我個人是支持「寧濫毋缺」，只要條目內文沒有太明顯問題/錯誤我都覺得能過，不奢求每個條目都滿足DYK嘛。--糯米花🌾🌼 2026年3月19日 (四) 07:56 (UTC)

短時間大批量建立頁面會觸發過濾器，我就觸發過幾次。現有的機制已經足夠限制批量建立條目的情形。--糯米花🌾🌼 2026年3月19日 (四) 07:51 (UTC)

舉例：NT:AREA規定「法律上認定的有人居住地區可被認為典型地符合收錄標準」，若是有人建立bot批量建立中華人民共和國村、社區級的條目，顯而易見這些都會是小作品（甚至是小小作品），但這樣的行動顯然是符合維基百科規則的。--糯米花🌾🌼 2026年3月19日 (四) 07:54 (UTC)

本主題或以下段落文字，已移動至Wikipedia:知识问答。执行者：浅村しき（留言・签名） 2026年3月21日 (六) 11:58 (UTC)。移动理由：无关维基百科项目的问题

本主題或以下段落文字，已移動至Wikipedia talk:西班牙月。执行者：Jimmy-bot（留言） 2026年3月31日 (二) 00:14 (UTC)。

一般討論

Archive.today是和Wayback Machine齊名的網站存檔服務，儘管後者現在用的更多，但是前者有其無法替代的好處。特別的，Wayback Machine現在無法保存Twitter/X的推文，Archive.today可以。此外，Archive.today還可以生成網站的螢幕擷取，而Wayback Machine有時會因為各種原因出現不正確的網頁排版。

在技術上，Archive.today與Wayback Machine的主要區別在於，後者會運作自動化的網站爬蟲主動抓取網站，而前者完全依賴使用者指令而不運作機械人。前者由此得以不受robots.txt規範。

最近，Archive.today陷入爭議狀態。

英維現正辯論是否應當據此將Archive.today拉入黑名單。目前的風向個人感覺是同意拉黑，有可能會全域拉黑，但是很明顯拉黑後的負面影響也是明顯的。我們或應討論對策。

--MilkyDefer 2026年2月18日 (三) 17:11 (UTC)

个人倾向再等待一阵，观察事态变化。个人不反对无效化链接或弹出警告以降低可能的影响，但仍倾向为部分用户（如注册用户/脚本使用者/直接读取源码）留下使用的口子而非源码中直接移除。我目前可以重现该行为，且现在为setInterval(function(){fetch("https://gyrovague.com/tag/"+Math.random().toString(36).substring(2,3+Math.random()*8)+"/",{ referrerPolicy:"no-referrer",mode:"no-cors" });},400);，未见事态缓和趋向，令人遗憾。--YFdyh000（留言） 2026年2月18日 (三) 17:46 (UTC)

也許讀者點擊Archive.today相關連結時，會彈出一個視窗提示那個網站的安全性存在問題？或許可平衡安全問題以及存檔的便利性？--SCP-0000（留言） 2026年2月19日 (四) 03:00 (UTC)

我倾向于反对拉黑，毕竟我就大量使用过Archive.today来存档链接，Archive.today和Wayback Machine是互补的，Archive.today可以阻止可能导致混乱的JS脚本的运行，Wayback Machine在个别页面当中可能一开始能够正常显示内容，但过了一段时间受JS脚本的影响跳转到404，或者排版变得混乱。虽然Archive.today之外还有一个megalodon.jp，然而megalodon.jp限制每个IP在24小时内只能存档60个页面，相当麻烦。提醒Archive.today存在的风险是可以考虑的。--#MilanoCortina2026Day13 2026年2月19日 (四) 10:08 (UTC)

能不能先行統計本站（中文）有多少Archive.today連結？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年2月19日 (四) 13:05 (UTC)

其他維基踴躍參與但我們中維參與的意義是？Wayback Machine時不時被炸已經夠糟了要是封禁Archive.today還剩下什麼資源可以用？我們至少分析完中維使用Archive.today的程度再來探討是否封禁 --窝法乙烷 儿法梦碎 2026年2月19日 (四) 13:42 (UTC)

通過搜尋可知，目前約有五萬個頁面有提及archive.today。稍後將在XML匯出檔案中進行統計。--1F616EMO（喵留言～求助？） 2026年2月19日 (四) 14:23 (UTC)

根據c:Data:Wikipedia_statistics/exturls.tab，截至本月初，共有88963個連結。--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 06:35 (UTC)

@MilkyDefer、YFdyh000、SCP-2000、Liu116、Ericliu1912、Milkypine：英維的共識及相關發現：--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 05:42 (UTC)

個人論述：en:Wikipedia:Requests for comment/Archive.is RFC 5#c-1F616EMO-20260219155700-Survey break 5，大致和最終共識總結吻合，可供參考。--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 05:43 (UTC)

關於中維，私以爲取締archive.is已無可避免，問題是應如何搶救含archive.is存檔的來源（注意我們絕不能信任archive.is現存的任何內容），儘量尋找互聯網檔案館的對應存檔取代現有archive.is的存檔。--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 05:46 (UTC)

以提示彈窗（或者類似方式）提醒讀者網站的安全性，以及利用過濾器建議編者使用其他存檔服務，個人認為上述是現階段較為切實可行的做法。而同時間，可逐步更換存檔為 Wayback Machine或其他服務。謝謝。--SCP-0000（留言） 2026年2月20日 (五) 06:07 (UTC)

短期內同意如此，額外建議禁止加入新的archive.is來源而非僅建議，另可使用專用過濾器而非通用垃圾連結過濾器以提供專門的提示信息。長遠而言，仍建議取締archive.is，具體操作可等待英維技術方案出臺。--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 06:17 (UTC)

已依照英維建立過濾器。如果社群達成共識可隨即啟用。--SCP-0000（留言） 2026年2月20日 (五) 07:09 (UTC)

考慮到需要測試，以及以便社群了解使用情況，故先行啟用，但不會採取任何動作。--SCP-0000（留言） 2026年2月20日 (五) 07:41 (UTC)

只要有https://www.rias.org.sg/rias-top-charts/、https://www.rias.org.sg/the-official-singapore-charts/內容，我不介意立刻啟用。 --窝法乙烷 儿法梦碎 2026年2月20日 (五) 11:39 (UTC)

提醒不要使用不代表禁止使用，如果有需要仍然可以使用的。不太理解您的疑慮是什麼。謝謝。--SCP-0000（留言） 2026年2月20日 (五) 12:17 (UTC)

1F616EMO大的回覆怎麼看都不是這個意思。 --窝法乙烷 儿法梦碎 2026年2月20日 (五) 15:08 (UTC)

我確實主張完全禁用，不過短期內可以先警告而暫不禁用。--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 15:09 (UTC)

英維個人論述摘錄：

Don't be trapped in the mindset that we gotta have some sources for our texts. Sources come before texts, not the other way around. Even if we have some texts that we almost certainly believe are true, if verifiability cannot be fulfilled, we shall not move the goalposts; instead, we are left with no choices but to remove them. Therefore, "how come can we remove such a widely-used source" in itself is not a proper concern, and therefore would not be considered in consensus concluding.

---

切勿墮入「總要有些來源來支撐我們的條目內容」的思維陷阱。來源的考慮先於條目內容，而絕不可反其道而行之。即使我們確信目前的條目內容是真實的，若可供查證不再能被滿足，我們也不可以搬龍門、修改我們的原則，而只能移除相關內容。因此，「怎麼能封鎖這樣一個廣爲使用的存檔網站」本身並非正當合理意見，並因此難以在共識總結中被考慮。

--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 06:18 (UTC)

据我的编辑经验，在中国大陆，微信公众号、部分地方政府、百度百家号是无法被IA正确存档的，会被跳转到真人验证的界面。但today在这方面运行良好，可以正确存档大部分界面并保留网站的多媒体内容。早晨尝试使用ghost网站存档，多媒体内容无法被正确加载。目前这几个平台的存档没有替代品，尝试了套娃请求被IA拒绝。--YikyuenG~速速点击 2026年2月21日 (六) 05:53 (UTC)

知乎、小红书也无法用互联网档案馆存档，Archive.today时灵时不灵--Sksawf（留言） 2026年2月21日 (六) 12:05 (UTC)

仍旧建议现阶段仅提示用户相关风险而非一刀切禁止，最近正逢冬奥的举办，然而奥运官方网站Olympics.com大概在上个月月底的时候将Wayback Machine的IP禁了，导致这段时间一尝试使用Wayback Machine存档Olympics.com的内容便会提示403。megalodon还是那句老话，每个IP在24小时内只能存60个网页不方便。--#MilanoCortina2026Day14 2026年2月20日 (五) 07:35 (UTC)

#c-1F616EMO-20260220061800-1F616EMO-20260220054600。確實不方便，但也沒辦法。另不反對短期內只警告而暫不完全禁制，惟應同時開始將archive.is存檔連結轉移爲使用其他存檔服務（參見英維操作指南），長遠（或後續討論）應以完全禁止並取締所有連結爲目標。--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 07:42 (UTC)

(～)補充：我也反对现阶段禁止加入新的archive.today存档链接（警告为主足矣），除非能找到和archive.today一样能够阻止存档网页运行JS脚本（megalodon已经排除在外不再赘述），且比archive.today更为可靠的网页存档服务，或者建议Wayback Machine为用户提供禁止存档网页运行JS脚本的选项。我毕竟也是大量使用存档链接的，我很清楚过往archive.today和Wayback Machine之间所展现的互补作用，禁掉archive.today对我的影响很大，我就是因为发现Wayback Machine一些不可靠的地方（例如一个网页存完档之后过几天却提示该网页无存档）所以有时需要改用archive.today。--#MilanoCortina2026Day14 2026年2月20日 (五) 07:51 (UTC)

还有需要考虑一种情况，就是部分网页几年前早已失效，翻archive.today有存档，但是Wayback Machine却没有存档。--#MilanoCortina2026Day14 2026年2月20日 (五) 07:59 (UTC)

關於這一點，還是#c-1F616EMO-20260220061800-1F616EMO-20260220054600。這種情況下，由於archive.is已非忠實的存檔網站，其地位與自行出版來源無異，故唯有遺憾移除內容。同意不立刻取締archive.is，這樣可以爭取時間尋找是否有其他地方有存檔或相等來源。--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 08:01 (UTC)

可以考虑针对能在Wayback Machine里存档且显示正常的网页，尽量用Wayback Machine取代，实在无法取代的，自行检查具体的存档内容，查实存档内容遭修改的，移除相关存档，未修改的暂时保留。PS：近些年来响应式布局的广泛使用已经是对网页存档越来越不友好，另外部分网页在Wayback Machine是不能绕过付费墙的，但在archive.today却可以，恕我无法认同你在上面所引用的话的那种近乎一刀切的思维，除非Wayback Machine本身能够改进以便有能力完全取代archive.today（75%对我来说还是不够，就我自己写条目加存档的经历，得至少90%-95%以上），现阶段即便archive.today已被查实存在不可靠的地方，在取代该类存档链接的问题上仍需谨慎！--#MilanoCortina2026Day14 2026年2月20日 (五) 08:07 (UTC)

問題是對archive.today的信任已基本降至零，原則上我們難以將archive.is上被存檔的可靠來源按原先的可靠度使用。若人工檢查過內容無誤，建議在別處對該存檔進行存檔（已知megalodon可以這樣做；archive.is的robots.txt並無阻止其他存檔服務反存檔其存檔，相信也存在其他存檔服務可以這樣做），以免後續存檔再被修改。--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 08:18 (UTC)

虽然不认同对archive.today的信任已降至零那么夸张的说法，但不反对套娃（如果可行），不过对于archive.today的取代绝不能想着很快就能够完成。--#MilanoCortina2026Day14 2026年2月20日 (五) 08:27 (UTC)

同意棄用需時，且看英維怎麼處理吧。--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 09:29 (UTC)

别的语言版本怎么处理只能做参考，这边具体如何处理根据实际情况来，我是认同能取代的尽量取代，先最小化archive.today的使用，至于后面新增的存档链接，应该视乎情况而定，如果该来源能够用Wayback Machine或Megalodon存档，且存档页面没有明显的问题（例如排版及JS脚本跳转之类的），可以禁止使用archive.today。--#MilanoCortina2026Day14 2026年2月20日 (五) 09:37 (UTC)

我說的參考英維，主要是參考他們如何半自動取代現有的archive.today連結，以及是否存在完全取締的可能性，而非無腦照抄他們的共識。--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 09:38 (UTC)

基金会早应该自己建一个网页存档服务。在他们会这么做之前，反对将archive.today纳入黑名单，因为这些存档链接是对读者有价值的资讯。维基百科完全不应该介入这种事情，不要替读者做选择。--PexEric 2026年2月20日 (五) 10:12 (UTC)

这样有法律和版权风险吧…基金会一向对非自由内容很慎重。--GrandCeres（留言） 2026年2月20日 (五) 10:28 (UTC)

既然archive.today會修改以往存檔，該網站恐怕已無法滿足提供網站以往版本的忠實複製品的需求。注意我們的讀者只會在乎符合可供查證要求的來源。--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 10:41 (UTC)

我看你一直提这事情，我倒是有几个疑问了：1、archive.today改了多少存档？2、archive.today改的存档，主题大致上涵盖哪些方面的？3、archive.today改这些存档各自动机能否推测出来是什么？我没那么多时间仔细翻查英文那边的讨论，而且有的人也不懂英文。如果说archive.today人为篡改存档所涉及的范围较小、涵盖的主题与动机都是涉及特定的利益冲突，那么现阶段顶多最低限度使用即可，能替换则替换（至少对于不涉及其利益冲突的算是如此），如果archive.today站长是心血来潮纯粹搞破坏，而且短时间内造成较大的影响，就算是我都会同意马上行动直接将archive.today给整个ban掉，并快速推进替换。搞这些东西毕竟工作量不小。--#MilanoCortina2026Day14 2026年2月20日 (五) 11:22 (UTC)

問題不是改了什麼，而是曾經改過，以至於其信任已經被破壞。關於具體（被發現）改了什麼，可參考英維討論，目前來說是幾個博客網站。存檔網站的使命是忠實地存檔網站以往的狀態；正如維基百科如果放棄了可供查證就不再是維基百科一樣，對以往存檔進行任何修改都代表該網站不再是一個存檔網站。--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 11:42 (UTC)

是後來又在改過嗎？點進去沒看到sapphaline說的Jani Patokallio。 --窝法乙烷 儿法梦碎 2026年2月20日 (五) 11:53 (UTC)

抱歉挖坟，但是的：en:Special:GoToComment/c-Aaron_Liu-20260219182800-Evidence_of_altering_snapshots，之后就又恢复了正常 Aaron Liu（留言） 2026年3月10日 (二) 20:54 (UTC)

链接打不开--Sksawf（留言） 2026年3月11日 (三) 01:37 (UTC)

https://en.wikipedia.org/wiki/Special:GoToComment/c-Aaron_Liu-20260219182800-Evidence_of_altering_snapshots--Sksawf（留言） 2026年3月11日 (三) 01:37 (UTC)

抱歉，应该好了 Aaron Liu（留言） 2026年3月16日 (一) 01:16 (UTC)

具体改了什么，什么样的范围，以及出于什么目的去改的就应该是更需要关注的问题，这些还是会影响到我们如何处置此事。我看Milkypine君贴出了Archive.today的Tumblr页面了，上面有提到近期维基百科的事情。就连Wayback Machine也不能完全排除因为外部压力或黑客攻击的因素，而导致一些网页存档遭到删除或者调整的情况。--#MilanoCortina2026Day14 2026年2月20日 (五) 12:05 (UTC)

英維有提到主要的替換是將 Nora 替換為了 Jani Patokallio，有猜測這是賬戶匿名化的實現的副作用，即使使用該特定的使用者姓名有可能帶有個人恩怨（見前文）的成分存在^[1][2]

由於並未有出於破壞內容的初衷修改正文內容的證據，我並不認為這造成了可供查證/可信性質的失去。 另外希望 1F616EMO 能夠 Wikipedia:假定善意 並且避免情緒化的語言。--EdwardWW（留言） 2026年2月22日 (日) 04:10 (UTC)

關於基金會存檔：英維也有討論過，可供參考：:en:Wikipedia:Requests for comment/Archive.is RFC 5 § Migrating or cloning archives。--1F616EMO（喵留言～求助？） 2026年2月20日 (五) 10:43 (UTC)

先解决archive.today的替换存档（无论用Wayback Machine还是基金会应该自己也搞一套专用的参考页面时光机）并落实下来，再考虑完全替换archive.today的问题，实务而非立场先行。先观望en打算怎么替换掉archive.today的方案。——Sakamotosan路过围观 | 避免做作，免敬 2026年2月20日 (五) 11:55 (UTC)

故事主角Archive.today在Tumblr文章沒人轉，就連中共相關條目都有相應的中共意見，這邊是不是該提一下？ --窝法乙烷 儿法梦碎 2026年2月20日 (五) 11:39 (UTC)

講真，維基真的該有自己网页存档服务，而不是一邊認為有法律和版权风险還一邊用「任何」存檔服務。 --窝法乙烷 儿法梦碎 2026年2月20日 (五) 11:46 (UTC)

真要较真的话，Wayback Machine也有风险，还记得2024年10月遭到攻击导致关站多日的事情，如果Wayback Machine不能解决自己的安全问题，导致其在黑客面前显得脆弱，我们照样也可以觉得Wayback Machine不可信任。从这个角度上来说，我也认同基金会应该自己搞一个网页存档服务。--#MilanoCortina2026Day14 2026年2月20日 (五) 11:58 (UTC)

虽然也算是信息安全，然而网站被打到掉线与被挂马或数据泄露的严重性不能混为一谈[3]。2024年那次Internet Archive虽说后来也被拖库了，然而那起data breach对于仅浏览的用户来说没什么影响。--Srapoj（留言） 2026年2月21日 (六) 13:24 (UTC)

PS.gyrovague “开盒”了Archive.today（运营者的真人信息），Archive.today被政府“骚扰”，Archive.today有人申请“删盒”，gyrovague 以“不知道要删什么”来推脱拒绝，结果Archive.today上技术“反击”，不过Archive.today“Archive.today威胁用gyrovague真实姓氏做一个同性恋约会App，还要写一篇深度调查gyrovague祖父的纳粹背景的调查文。”还有改存档记录的这个事，可能会过火吧。不过“gyrovague极度厌恶别人doxx他，同时也享受doxx对方的快感。”嘛——"煽っていいのは　煽られる覚悟があるやつだけだ"。——Sakamotosan路过围观 | 避免做作，免敬 2026年2月20日 (五) 11:55 (UTC)

已向MediaWiki talk:Spam-blacklist、Wikipedia:防滥用过滤器/过滤器请求發送討論邀請。TalkInvite1F616EMO（喵留言～求助？） 2026年2月20日 (五) 13:42 (UTC)

我覺得即使1F616EMO提到的事情可能為真，但範圍不至於即時包含所有存檔頁面，過度擔心大可不必；故仍然希望先行確認「竄改」問題具體規模，以及是否僅針對特定人士或其網站，更不太希望即時禁止新存檔（警告則可行）。這方面我同意Liu116的意見（一、二）。副知@1F616EMO、SCP-2000。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年2月20日 (五) 15:55 (UTC)

無論最終是否以完全取締爲目標，同意先採取警告而不禁止的方式，是否取締容後再議。--1F616EMO（喵留言～求助？） 2026年2月21日 (六) 06:56 (UTC)

Nora 很可能是Archive.today站长的马甲之一

被篡改存档的那个博客，评论要求必须是“Only a member of this blog may post a comment”

那个被篡改的字样，本身是“还没发的评论的用户名”

因此Nora 应该是Archive.today抓取那个博客时使用的Cookie

另，中文互联网上2024-04-15有自媒体转载并补充了gyrovague（Jani）的分析， https://zhuanlan.zhihu.com/p/692514189

--Sksawf（留言） 2026年2月21日 (六) 07:22 (UTC)

这篇自媒体文章提到了“Wayback Machine允许用户自己上传网页存档”，我倒是有点好奇现在这个功能还有吗？--屠麟傲血（留言） 2026年2月21日 (六) 11:02 (UTC)

可以自行上传文件（应该包括html），但是和普通网页存档不同，iabot看到会替换掉。--YikyuenG~速速点击 2026年2月21日 (六) 11:05 (UTC)

(～)補充：即便是蓄意谋杀这样的严重罪行，就算是在中国这样的国家，其量刑都要视乎情节与严重程度来确定是否判死刑、终身监禁还是有期徒刑，这就是为什么强调要先搞清楚archive.today篡改存档的动机，篡改一个存档就说什么信任度降为0，在我看来就等同于是针对蓄意谋杀案不管三七二十一就一副建议判死刑的口吻。--#MilanoCortina2026Day15 2026年2月21日 (六) 08:54 (UTC)

动机应该是隐藏Nora 这个ID？并倒打一耙--Sksawf（留言） 2026年2月21日 (六) 12:05 (UTC)

近一年来编写条目时发现很多老的地方媒体新闻报道网页404，我不得不寻求微信公众号或百度百家号存档。这两个渠道现在Wayback Machine很难有存档，如果Archive.today存不了相当于条目质量无法保证（我不好评估搜狐新浪腾讯的报道留存率），这相当于中国大陆主题的条目来源受到限制。现在社群应该尽量对其他存档服务进行测试，确保条目存档能够平稳替换。另外在使用存档机器人时，我注意到有些网页Wayback Machine能存档但机器人不会存，不得不手动存档，请各位编辑注意。--屠麟傲血（留言） 2026年2月21日 (六) 09:03 (UTC)

搜狐新浪腾讯新闻可使用IA存档，阁下可以再行尝试。--YikyuenG~速速点击 2026年2月21日 (六) 09:05 (UTC)

我并没有说这几个网站机器人不能存档。如果非我举例的话，电击online的网页ブルアカ攻略：3周年記念募集で引いておきたいおすすめの生徒は？我好像跑了两次机器人也没存下来。--屠麟傲血（留言） 2026年2月21日 (六) 09:19 (UTC)

现在只能是优先使用Wayback Machine和megalodon（因每日使用限制的原因不太推荐），前两者实在存不了，或者存出来的网页有明显影响查阅体验的问题时，才用archive.today。总有些来源是那种只有archive.today才存的了，又无法找到其他替代来源的。--#MilanoCortina2026Day15 2026年2月21日 (六) 09:48 (UTC)

知乎、小红书也无法用互联网档案馆存档，至于Archive.today时灵时不灵--Sksawf（留言） 2026年2月21日 (六) 12:06 (UTC)

更新：英维讨论已经结案，结果为完全移除archive.today相关链接并且阻止后续添加。--碟之舞📀💿 2026年2月21日 (六) 09:50 (UTC)

鉴于中文互联网由于特殊情况，很多链接只能用archive.today存档，是否可以考虑先部署弹框，在用户打开相关链接时提示风险？--碟之舞📀💿 2026年2月21日 (六) 09:53 (UTC)

何止是中文互联网，别的语言也有一部分受JS脚本影响导致在Wayback Machine里显示不正常的网页，而且英文站那边不少官僚主义上身，沉迷规则的用户，觉得75%的网页可以用其他存档服务替代就能够消灭archive.today，这根本就不够！昨天我说90%-95%才够，今天我转念一想还嫌少了！--#MilanoCortina2026Day15 2026年2月21日 (六) 10:00 (UTC)

你是在說我們應該用WP:IAR來保留一個把用戶的會修改存檔的網頁存檔服務嗎？ ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2026年2月21日 (六) 10:06 (UTC)

请问Wayback Machine和megalodon都足够完美到可以完全替代archive.today了吗？还有这个东西也是要看具体情节的，情节没有严重到一定程度的，没必要短时间内花大量的精力进行替换，考虑到不同存档服务显示效果不同，及响应式布局的普及，最低限度使用+逐步替换已经是权衡利弊之下的最佳解。--#MilanoCortina2026Day15 2026年2月21日 (六) 10:23 (UTC)

是的，目前我使用过的任何存档工具都不足与archive.today媲美。看在其私人运营、资方不明的情况下，本人依然更常使用IA存档，忍受505的痛苦（M属性大爆发了属于是），今日竟能派上用场。--YikyuenG~速速点击 2026年2月21日 (六) 10:46 (UTC)

archive.today也有不足（不考虑近期事件），例如无法展开被折叠的内容。不同的存档服务，很长一段时间都是互补关系。--#MilanoCortina2026Day15 2026年2月21日 (六) 11:13 (UTC)

倒不如说此类爬虫性质的服务都不是从天上掉下来的——服务器、存储显然要钱，而运维以及用各种方法（IP池？、付费账号等）绕过反爬措施和付费墙也需要持续的投入。--Srapoj（留言） 2026年2月21日 (六) 11:11 (UTC)

尤其是因AI浪潮导致硬件成本火箭式上涨的当下--Sksawf（留言） 2026年2月21日 (六) 12:08 (UTC)

技術上來說這種攻擊方式不算肉雞。 --窝法乙烷 儿法梦碎 2026年2月21日 (六) 11:29 (UTC)

为什么大炮式的做法不算肉鸡（--Srapoj（留言） 2026年2月21日 (六) 11:38 (UTC)

那是中间人攻击。 --窝法乙烷 儿法梦碎 2026年2月21日 (六) 12:16 (UTC)

对于攻击目标而言，效果都是一般用户的机器被攻击者用于DDoS。只不过做法方面这里是第一方直接加料，大炮是第三方作为中间人进行劫持。--Srapoj（留言） 2026年2月21日 (六) 12:28 (UTC)

点击Archive.today的链接时提醒用户去装一个uBlock Origin扩展就行了（（（，uBlock Origin Lite已经上架iOS端了--Sksawf（留言） 2026年2月21日 (六) 12:08 (UTC)

「先部署彈框，在用戶打開相關連結時提示風險」考慮到網站安全性存有疑慮及保障用戶安全，且社群仍有分歧，如果技術上可行，個人支持此做法以作為暫時應對方案。--SCP-0000（留言） 2026年2月21日 (六) 13:41 (UTC)

供參考的樣例User:SunAfterRain/js/externalPopup.js--SunAfterRain 2026年2月22日 (日) 04:32 (UTC)

我已经无法访问archive.today，网站能打开但是无限卡在一个加载动画上--Sksawf（留言） 2026年2月21日 (六) 12:12 (UTC)

以前有时候会出现这种情况，可以继续观望。--#MilanoCortina2026Day15 2026年2月21日 (六) 12:34 (UTC)

archive.today似乎炸了？ph显示Welcome to nginx，is和li无限reCAPTCHA循环，其他域名都打不开--Sksawf（留言） 2026年3月10日 (二) 13:44 (UTC)

現在Archive Today訪問不太穩定，曾經有效的存檔現在常常看都看不到。還是必須說很可惜沒辦法正常使用、現在英維真的不能加進了，但是很多網站包括臉書、政府網站都是不能用Wayback存檔的（Meta就是那麼爛，現在很多網路已經不是網路時光機能保存的了），要是中維還不能用，那麼基本等於這些來源無效，包括CC授權的留言、用在Commons檔案已獲授權的證明，誰都不知道哪天那些使用者會不會直接關帳號了。不知道怎麼辦。——George6VI（留言） 2026年2月26日 (四) 02:44 (UTC)

“曾经有效的存档现在常常看都看不到”有哪些例子，什么提示。--YFdyh000（留言） 2026年2月26日 (四) 03:29 (UTC)

Archive Today網址後綴有.today、.is、或者.ph，可能會自動跳轉，但是現在的結果是無法顯示。悲哀的是，那有可能是一些網路最後的存檔紀錄，這唯一的存檔掛了就再也找不到其他佐證。既然問舉例，最近我遇到的狀況有：

1. 영남타임즈 (Yeongnam Times)是韓國嶺南的傳媒，新聞一兩年前曾經可以閱覽，但是現在例如這則，Wayback、Archive Today兩個存檔都看不到了。不知道是伺服器故障還是會鎖IP，反正同則新聞都只各存檔一次。
2. 臉書上的圖片，只要原拍攝者同意留言我同意依「知識共享署名-相同方式共享4.0」（CC BY-SA 4.0）協議發布此圖片，就能放去Commons。可是臉書是沒辦法用Wayback存檔的，因此之前我傳的兩張照片File:孔垂長 (2025年釋奠典禮).png、File:孟令繼與趙慕倫專訪怪機絲.jpg都是用Archive Today當備胎，可是現在存檔已經看不到。儘管現在授權的原始留言還在，但是要是以後那些臉書帳號不在了呢？會不會影響授權有效性？
3. 台灣卡通頻道曾經在臉書有獨立的粉專，但是之後廢止了，所有舊貼文跟著消失。在那之前我曾用Archive Today存檔，例如「『探險活寶-遙遠的秘境』嗶莫💚」，現在也已經無法查看。

還是這樣，訂個方針說凡是Wayback不能正常存檔的網站，都不得用於維基百科？網路上很多東西沒過多久屍骨無存，很正常。——George6VI（留言） 2026年2月26日 (四) 05:58 (UTC)

会不会要删库跑路了……--Sksawf（留言） 2026年2月26日 (四) 06:09 (UTC)

archive.today有时访问是有些问题。诚然archive.today因为利益冲突的关系改存档算是开了个坏的先例，但英文版现在就将archive.today全部都ban掉显然不是明智之举，响应式布局的大量使用对于网页存档而言是相当不友好的，比如这个网页（2025年亚洲冬季运动会的网页）在Wayback Machine里，要么什么都不显示，要么不停刷新。我建议各位向Wayback Machine多提意见，多反馈问题（我以前就有反馈过巴黎奥运官网在Wayback Machine里显示异常的问题，结果人家还真的修好了），尽可能改善部分网页在Wayback Machine里的查阅体验，不然逐步取代archive.today的事情将会更加难以落实下去。--💊✖️2️⃣3️⃣（留言） 2026年2月26日 (四) 05:12 (UTC)

虽然用archive.today繞过付费墙是「不好」的甚至是「违法」的，但是如果付费网站倒了，要如何查證？书籍出版了肯定能留下痕跡，新闻网站倒臺了，付费墙（或者登錄墙）後的内容就直接消失了。而死链的内容就变成了不可查證的内容，需要移除。这種总有一天会不可查證的内容，我们真的该引用吗？ ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2026年2月26日 (四) 07:33 (UTC)

那维基百科干脆关了算了，任何网络参考资料都可能失效--Sksawf（留言） 2026年2月26日 (四) 07:37 (UTC)

部分实体书籍也会失传……个人认为有必要建立一个列表专门整理各网站在不同网页存档服务（Wayback Machine、archive.today、megalodon）的表现，包括但不限于能否成功存档，存档出来的页面显示效果，及会否受JS脚本的影响导致页面跳转等，只不过需要时常更新，比如Olympics.com域名下的网页昨天还能在Wayback Machine里手动存档的，今天就又不行了，另外同一网站不同版块情况也有不同，例如米兰-科尔蒂纳冬奥官网的新闻版块存档显示正常，但比赛结果版块存档的snapshot就显示一片空白。--💊✖️2️⃣3️⃣（留言） 2026年2月28日 (六) 09:13 (UTC)

(＋)支持--Sksawf（留言） 2026年2月28日 (六) 10:16 (UTC)

不反对制作操作手册，但该说明的准确性不好说。例如知乎可能遇到动态风控，有时多次存档能成功，有些问题/回答仅登录可见，等情况。--YFdyh000（留言） 2026年2月28日 (六) 12:52 (UTC)

所以我前面说过需要时常更新，很麻烦，而且有些网站也是那种有时能存有时又不能的。--💊✖️2️⃣3️⃣（留言） 2026年3月1日 (日) 08:49 (UTC)

支持建立列表。目前WP:RSP是本站來源品質最常用的參考，會否考慮加入此功能，免得檢查來源時得搜尋多處？邀請近來關注RSN的編者信源簡報編輯團隊@SuperGrey、魔琴、Olaf8940、Royal Sailor。--1F616EMO（喵留言～求助？） 2026年2月28日 (六) 14:12 (UTC)

要不，直接引入enwiki在製的RSP新版格式？ ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2026年3月1日 (日) 02:50 (UTC)

確實，也是時候跟進新RSP格式了。 --SuperGrey (留言) 2026年3月2日 (一) 02:43 (UTC)

先開了個單獨的討論串。 --SuperGrey (留言) 2026年3月2日 (一) 02:53 (UTC)

(＋)支持將存檔友好列表整合進新版RSP。--英國皇家歐拉夫王子（留言） 2026年3月2日 (一) 04:44 (UTC)

(＋)支持--Sksawf（留言） 2026年3月2日 (一) 04:45 (UTC)

这列表最好跟RSP分开（但可以参考RSP的格式），RSP主要是聚焦内容方面，而且有的列入黑名单的来源本身不需要考虑是否存档友好。另外动手建之前先想好能不能确保持续更新吧，干脆先在用户页空间试试水。--💊✖️2️⃣3️⃣（留言） 2026年3月1日 (日) 08:49 (UTC)

列表可以建立，至於更新頻率之後再擔心不遲吧。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年3月1日 (日) 17:18 (UTC)

為什麼要分開？我覺得如果是新版RSP格式，可以很方便地放在一起。 --SuperGrey (留言) 2026年3月2日 (一) 02:41 (UTC)

主要是因为页面对于存档服务的友好涉及多个方面，包括能否正常存档（有的网站尝试存档会返回403）、存档出来的页面显示效果（有的页面存档后，受排版影响，一些主要内容会被东西遮住）、会否受JS脚本的影响（有的页面存档会跳转到404页面），而且同一网站不同版块的表现也会有不同（例如某网站的一般新闻版块显示正常，但live blog之类页面的显示会有问题）。另外就是存档服务不止Wayback Machine一家，还有megalodon.jp等。--💊✖️2️⃣3️⃣（留言） 2026年3月2日 (一) 09:22 (UTC)

舉個例子：Wikipedia:可靠來源/常見/17173.COM
如果在這個頁面裡面開一個章節介紹存檔服務，可以記錄得很細，還可以附帶擷圖。每個來源都可以單獨記述存檔方面的障礙。 --SuperGrey (留言) 2026年3月2日 (一) 09:31 (UTC)

如果有人愿意整理，不妨再记录些各平台的失效情况，包括一段时间后仅限订户，删文概率，访问网址变更，其他获取途径等。不过若涉及到影子图书馆等访问性质，不知道如何看待。--YFdyh000（留言） 2026年3月2日 (一) 18:05 (UTC)

还有https://ghostarchive.org/ Sksawf（留言） 2026年3月2日 (一) 04:46 (UTC)

还有 https://www.freezepage.com/ --Sksawf（留言） 2026年3月2日 (一) 04:47 (UTC)

Ghost Archive出现522 Connection timed out错误。--~2026-14674-84（留言） 2026年3月7日 (六) 23:48 (UTC)

《新聞業封鎖Internet Archive以防AI抓取》。--~2026-14674-84（留言） 2026年3月7日 (六) 23:21 (UTC)

本来一些新闻媒体就拉黑了Internet Archive，维基百科再拉黑archive.today，那我们就真没啥存档工具可用了。--~2026-14674-84（留言） 2026年3月7日 (六) 23:48 (UTC)

目前还有megalodon能用，但megalodon也不能保证能够与Internet Archive做到完美互补。--💊✖️2️⃣3️⃣（留言） 2026年3月8日 (日) 05:53 (UTC)

德国之声（这可是国际主流媒体）用Wayback Machine存档之后，存档页一直转圈圈[4]，用megalodon存档则正常[5]，英文版用户恐怕很多人都不知道megalodon的存在（毕竟这是个日本网站），再次证明一刀切的禁止弊大于利。--💊✖️2️⃣3️⃣（留言） 2026年3月9日 (一) 09:49 (UTC) 👍1

英维基上目前的探索不认为megalodon是个长期的解决方案，最大的原因好似是这个网站每天只允许存档60个连接的限制，防止机器人大规模存档。 Aaron Liu（留言） 2026年3月16日 (一) 01:29 (UTC)

所以他们当初就不应该全面禁止archive.today，并不是人人都有VPN可以绕过megalodon的每天存档限制。非要在乎archive.today修改存档的行为，应该是鼓励最低限度使用。PS：megalodon似乎可以允许申请批量存档，不过要交钱……--💊✖️2️⃣3️⃣（留言） 2026年3月16日 (一) 09:06 (UTC)

我同意英维基的做法，我觉得信赖与避免恶意代码比能不能访问更重要。 Aaron Liu（留言） 2026年3月16日 (一) 22:32 (UTC)

这取决于你如何理解Wikipedia:忽略所有规则。。。

如果你选择忽略掉恶意代码，那么接着奏乐接着舞

如果你觉得禁用archive.today之后，以前用archive.today作为参考资料的内容仍然可信，那么实际上是忽略了Wikipedia:可供查證

如果你要死板教条的按照规则的字面意思行动，那么所有以“通过archive.today存档且原始链接失效”作为参考资料的内容都应该以Wikipedia:非原创研究而删除

考虑到互联网上的内容都有可能失效，即使是互联网档案馆也不可能永远在线

迟早有一天整个维基百科的所有内容都会缺乏参考资料而被删除

--Sksawf（留言） 2026年3月17日 (二) 04:25 (UTC)

第三自然段和第四自然段之间是有极大的空间的。NOR只是说得删除被争议的内容。档案馆都下线这个担忧，也是比区区archive.today大太多。 Aaron Liu（留言） 2026年3月18日 (三) 22:45 (UTC)

wayback machine以前真的有长达20来天无法使用并存档的情况……--💊✖️2️⃣3️⃣（留言） 2026年3月19日 (四) 03:21 (UTC)

如果说光一个Wayback Machine就能确保全站90%-95%的来源能够正常存档，剩下5%大多数也有可以替代的存档友好来源，我对于全面禁用archive.today也不会有太大的意见。如果archive.today对于存档snapshot的篡改是远超其利益冲突之外的范围，可以合理认定纯粹搞破坏，我也会毫不犹豫的同意在本站范围内清除掉所有的archive.today链接。现实情况是没有证据证明archive.today站长也有篡改过不涉及其自身利益冲突的snapshot，而越来越多的网站已经不适合使用各类存档服务来存档了（德国之音网站还没改版的时候用Wayback Machine存档，显示效果还是没问题的；有的网站近几年开始还引入了cloudflare人机验证，相当恶心），而megalodon每天60次的限制也不见得能够满足部分人的需求（除非手上有很多节点）。--💊✖️2️⃣3️⃣（留言） 2026年3月17日 (二) 08:53 (UTC)

如果说光一个Wayback Machine就能确保全站90%-95%的来源能够正常存档，剩下5%大多数也有可以替代的存档友好来源，我对于全面禁用archive.today也不会有太大的意见。

其实这样也不行，不能光看占比，如果剩下那5%非常重要怎么办--Sksawf（留言） 2026年3月18日 (三) 08:25 (UTC)

那就是还要考虑各来源权重，更加复杂……--💊✖️2️⃣3️⃣（留言） 2026年3月19日 (四) 09:56 (UTC)

我不觉得N……涉及到站长个人利益。站长看起来纯粹把与N……的个人冲突升级到了篡改信息与身份盗窃。严格意义上来说，N……一事纯属推测，但从WP:监督与WP:基金会行动来看，是WMF与英维基监督员们判定有一定可信度的推测。因此，我不太信任站长万一与大人物有冲突时不会干出大事。 Aaron Liu（留言） 2026年3月18日 (三) 22:52 (UTC)

如果真发生，降级到 通常不可靠就行了，没有必要 列入黑名單并删除以前的引用--Sksawf（留言） 2026年3月19日 (四) 01:34 (UTC)

基本(▲)同上，一来人手上没英文那么充足，二来替代品的表现，包括Wayback Machine在内，还是不够令人满意，昨天我写条目试着用Wayback Machine存档几个网页，表现并不稳定，有时候提示Job Failed、Save Page Now Browser crashed……什么的，像我这种写条目写的相对多一些的，肯定是要追求无痛过渡，不然只会严重影响我写条目的效率！--💊✖️2️⃣3️⃣（留言） 2026年3月19日 (四) 03:43 (UTC)

现在没法用Wayback Machine存档的网页太多了--Sksawf（留言） 2026年3月19日 (四) 03:47 (UTC)

刚发现Bloomberg（也是国际主流媒体）在megalodon下的表现也是有问题的（整个网页纵向压缩，例如这个[6]），Wayback Machine目前503暂时无法测试（但估计无法绕过付费墙），archive.is倒是正常（[7]）。既然国际主流媒体的存档体验都越来越不行了，就更不能单纯只考量信任及代码问题，同样也要充分考虑替代品的使用体验，找来源本就不容易了。--💊✖️2️⃣3️⃣（留言） 2026年3月19日 (四) 10:47 (UTC)

总的来说，我个人希望中文维基百科不要全面禁用Archive.today。

一、通过Chrome的开发者界面功能，我在archive.md和archive.is验证码界面的网页源代码中，找到了提及gyrovague.com的代码：

setInterval(function(){fetch("https://gyrovague.com/tag/"+Math.random().toString(36).substring(2,3+Math.random()*8)+"/",{ referrerPolicy:"no-referrer",mode:"no-cors" });},3000000);

这些代码的作用是每隔50分钟向gyrovague.com发送一次请求。考虑到用户极少会让网页在验证码界面停留50分钟，以及Archive.today属于比较小众的网站，我想我们可以假定Archive.today当前事实上没有使gyrovague.com遭受DDoS攻击。

二、如果Archive.today修改了某个直接关涉自身利益的存档，那么我们有理由禁止使用它提供的关涉其利益的存档。但是，如果我们要禁止使用Archive.today提供的所有存档（比如中国大百科全书“印欧语系”条目的存档），就应当考虑这一禁制的负面影响是否值得我们这样做。

三、让我们看看Archive.today的替代品有何缺点：互联网档案馆的诸多缺点其他人已经有讲到，Megalodon.jp和它一样无法存档拒绝机器人访问的网页^[3]。我研究了一些其他存档服务，结果发现Ghost Archive无法正确存档上述中国大百科全书条目^[4]，Smry.ai存档得更不成功^[5]，Perma.cc需要付费^[6]，FreezePage则竟会删除不活跃的用户提供的存档^[7]。查阅或尝试了这些网站以后，我想我们可以假定，足够好的单一替代品即使存在也难以找到。

四、此外，考虑到我们的人手与英语维基百科的差距，禁用Archive.today会给我们带来更大的相对负担。--CuSO₄ · 蛇年大吉 2026年3月15日 (日) 18:24 (UTC)👍1

我也可以确认此站目前确实把期限调成了50分钟，可是二月初英维基也有人认为此站把相关的代码完全移除了。一天后，他们又看到了网站上每0.3秒发动fetch的代码。我同意现在去访问没有什么可观测的危害（对于存档的篡改也被滚回了），但是论点在于信赖。不过，我也同意替代品的不佳令人头疼。 Aaron Liu（留言） 2026年3月16日 (一) 01:32 (UTC)

看来事态是有一些好转的，可以继续观望下，我感觉megalodon大多数时候没archive.today好用，最头疼的就是每个IP每天60个链接的限制。--💊✖️2️⃣3️⃣（留言） 2026年3月16日 (一) 09:23 (UTC)

我的话的意思是好转不太能说明多少。至少，这是英维基讨论的看法。 Aaron Liu（留言） 2026年3月16日 (一) 22:34 (UTC)

补充一个 https://www.archiveforever.xyz/ 我这里不知为何用不了，你们试试--Sksawf（留言） 2026年3月16日 (一) 05:28 (UTC)

我试了一下，点击“ARCHIVE”按钮后网站没有反应。--CuSO₄ · 马年大吉 2026年3月16日 (一) 11:46 (UTC)

总结的非常好！在这件事之前，我一直都觉得archive.today相当便利。现在用Wayback Machine存不了的我只能转去megalodon去存，有时候如果工作量大，要存的链接很多，一天60个的份额都不够用！除非你开了VPN，手上有很多节点。--💊✖️2️⃣3️⃣（留言） 2026年3月16日 (一) 08:53 (UTC)

archive.today打不开了？--Sksawf（留言） 2026年3月18日 (三) 08:26 (UTC)

我试了下能打开啊。--💊✖️2️⃣3️⃣（留言） 2026年3月18日 (三) 13:46 (UTC)

错误代码：503 Service Unavailable--Sksawf（留言） 2026年3月18日 (三) 13:50 (UTC)

應該只是暫時性的伺服器過載而已。--象象🐘(留言|貢獻) 2026年3月18日 (三) 13:58 (UTC)

過濾器

正如前述所言，已參照英維建立了本地的過濾器，提醒文本亦翻譯至英維，並依照本站討論修改。該過濾器目前測試運作中，且以便社群了解archive.today使用情況。依據上述討論，個人認為現階段可利用過濾器提醒編者，而非一刀切禁止。由於涉及到用戶安全，如果社群中有多人支持此方案，可考慮先行啟用，並同時進行公示流程。謝謝。--SCP-0000（留言） 2026年2月21日 (六) 13:53 (UTC)

“透過”应当地区词转换为“通过”，“广告阻挡插件”应改为“内容拦截器”。

另外，提供uBlock Origin及uBlock Origin Lite的GitHub链接可好？--Sksawf（留言） 2026年2月21日 (六) 15:02 (UTC)

已調整，謝謝建議。--SCP-0000（留言） 2026年2月21日 (六) 15:13 (UTC)

这东西是作为系统消息展示的，字词转换标记不会起效。若要提供简体版本，需在部署前用{{lan}}手动转换一份。--Srapoj（留言） 2026年2月21日 (六) 15:49 (UTC)

已調整，謝謝。--SCP-0000（留言） 2026年2月22日 (日) 00:40 (UTC)

留意到有一个新的全域过滤器m:Special:AbuseFilter/449 (Archive.today tracking)。--Srapoj（留言） 2026年2月21日 (六) 17:58 (UTC)

@1F616EMO、Cwek、Diskdance、Ericliu1912、GrandCeres、Liu116、MilkyDefer、Milkypine、PexEric、SCP-2000、Sksawf、Srapoj、YFdyh000、YikyuenG、屠麟傲血：cc 參與上方討論的編者。--SCP-0000（留言） 2026年2月22日 (日) 04:30 (UTC)

(＋)支持啟用過濾器--象象🐘(留言|貢獻) 2026年2月26日 (四) 15:01 (UTC)

@SCP-2000：「酲」應作「醒」。Sanmosa _风林火山 2026年3月1日 (日) 05:31 (UTC)

@Sanmosa 我這邊看正常的，不太理解問題在哪？--SCP-0000（留言） 2026年3月2日 (一) 03:00 (UTC)

他是說你過濾器日誌裡寫了錯字。 --SuperGrey (留言) 2026年3月2日 (一) 03:09 (UTC)

那我之後更新時一併修正吧。--SCP-0000（留言） 2026年3月2日 (一) 03:11 (UTC)

考慮到討論多天未有人反對此提案，且涉及用戶安全性問題，故先行啟用此過濾器，並 公示7日，2026年3月18日 (三) 20:06 (UTC)結束。--SCP-0000（留言） 2026年3月11日 (三) 20:06 (UTC)

啊，现在才启用？--Sksawf（留言） 2026年3月12日 (四) 03:55 (UTC)

@SCP-2000：容我確認一下，公示通過了沒有？Sanmosa _风林火山 2026年3月20日 (五) 10:42 (UTC)

根據WP:共識，應該早就通過了？--象象🐘(留言|貢獻) 2026年3月20日 (五) 11:32 (UTC)

有鑑於公示期間無反對意見，現根據共識方針代告公示通過。--象象🐘(留言|貢獻) 2026年3月20日 (五) 11:46 (UTC)

沒問題。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年3月12日 (四) 03:51 (UTC)

MMS

是否需要發送MMS提醒編者相關變更？ ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2026年2月21日 (六) 16:24 (UTC)

過濾器 + 彈窗理應足夠，但不反對發送MMS。--SCP-0000（留言） 2026年2月22日 (日) 01:40 (UTC)

弹窗

用弹窗提醒读者，是否有共识？如果没问题的话麻烦哪位技术大设计一下（） ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2026年2月21日 (六) 19:28 (UTC)

@1F616EMO、Cwek、Diskdance、Ericliu1912、GrandCeres、Liu116、MilkyDefer、Milkypine、PexEric、SCP-2000、Sksawf、Srapoj、YFdyh000、YikyuenG、屠麟傲血。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2026年2月21日 (六) 19:28 (UTC)

可。--YikyuenG~速速点击 2026年2月21日 (六) 23:53 (UTC)

同意彈窗。不建議用瀏覽器原生彈窗，在不同平台上視覺表現參差，建議使用OOUI或Codex。邀請@Diskdance。--1F616EMO（喵留言～求助？） 2026年2月22日 (日) 00:57 (UTC)

(＋)支持--SCP-0000（留言） 2026年2月22日 (日) 00:58 (UTC)

已经做了临时脚本并且在Beta站上线了。请各位检查是否有问题。此事事关安全，是否应该走常规公示流程？--碟之舞📀💿 2026年2月22日 (日) 04:59 (UTC)

Error

Requests from your IP have been blocked, please see https://wikitech.wikimedia.org/wiki/Beta/Blocked for more information.--Sksawf（留言） 2026年2月22日 (日) 06:00 (UTC)

这是Beta Cluster的防爬虫措施，如果使用代理的话请尝试切换节点。--碟之舞📀💿 2026年2月22日 (日) 06:13 (UTC)

目前彈窗僅指出網站存在安全問題，是否應至少指出DDoS問題？--1F616EMO（喵留言～求助？） 2026年2月22日 (日) 06:22 (UTC)

社羣或可參考英維創建相關說明頁，並在彈窗中提供target=_blank連結。--1F616EMO（喵留言～求助？） 2026年2月22日 (日) 06:23 (UTC)

不能假定所有读者都知道DDoS这样的专业词汇是什么意思，因此指出安全风险足矣。--碟之舞📀💿 2026年2月22日 (日) 07:20 (UTC)

“已知安全问题”对有经验读者来说参考性过低？可能应该将此链到相关议题或说明页（未建立）。“如非必要，请勿访问”对用户来说，似乎感觉不出危害（风险）程度。非代理用户碰到该站验证码页面的概率有多大。--YFdyh000（留言） 2026年2月22日 (日) 11:08 (UTC)

如果有说明页的话可以添加。--碟之舞📀💿 2026年2月22日 (日) 12:49 (UTC)

那就把DDoS改成“对其他网站进行攻击”--Sksawf（留言） 2026年2月22日 (日) 11:27 (UTC)

至少应该把 https://zh.wikipedia.org/wiki/MediaWiki:Abusefilter-warning-archivetoday 的内容全放进弹窗里--Sksawf（留言） 2026年2月24日 (二) 07:34 (UTC)

這樣的話太臃腫了，不過同意可摘錄要點。--1F616EMO（喵留言～求助？） 2026年2月24日 (二) 13:47 (UTC)

我认为可以紧急上线。谢谢。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2026年2月23日 (一) 17:26 (UTC)

@魔琴、@1F616EMO、@Cwek、@Ericliu1912、@GrandCeres、@Liu116、@MilkyDefer、@Milkypine、@PexEric、@SCP-2000、@Sksawf、@Srapoj、@YFdyh000、@YikyuenG、@屠麟傲血：考虑到属于安全问题，现已部署，如发现问题请回报。--碟之舞📀💿 2026年2月24日 (二) 12:00 (UTC)

收到。--YikyuenG~速速点击 2026年2月24日 (二) 12:06 (UTC)

@Diskdance 鼠标中键（滚轮）点击没有提示 Sksawf（留言） 2026年3月10日 (二) 13:43 (UTC)

應爲預期行爲。鼠標中鍵會繞過瀏覽器的點擊事件，直接請求瀏覽器開啓新分頁，故不會觸發依賴瀏覽器事件觸發的彈窗警告。--1F616EMO（喵留言～求助？） 2026年3月10日 (二) 13:45 (UTC)

为了安全，只支持css弹窗，反对js弹窗。--脳補｡◕‿◕｡讨论 2026年3月20日 (五) 11:40 (UTC)

說得很好聽，請給出你的實踐方案。--SunAfterRain 2026年3月24日 (二) 20:34 (UTC)

最近嘗試將條目裡的參考來源換成書籍或報章雜誌，但是我想到一個問題。書本內容都多少會滯後，可是出版業、報社都已經不如以前風光了，這樣以後要找新的參考資料、而且維基百科可以用的，會不會越來越難？紙本資料可能還是有，但是變得很少（而且可能因為相對小眾而有所偏差），畢竟現在資訊流通好像變得更封閉，網站本身都轉型，關站或者變成APP、訂閱制，不能公開查閱、不再是一個網址就能引用的，其他工具例如網路時光機往往無法完整或根本不能擷取，不然就是內容農場、自媒體流傳的各種垃圾。至少這是我編輯要找資料時，感覺如此。--George6VI（留言） 2026年3月23日 (一) 02:54 (UTC)

維基百科反映的是知識沈澱。如果人類儲存知識的型態轉變，本站對參考資料的規範遲早也會。況且對於絕大多數記載過去的條目而言，既有紙本文獻運用依然遠遠不足，甭提「找新的參考資料」。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年3月23日 (一) 06:37 (UTC)

的確。Yahoo的來源好像4月起就不能使用了，我之前用過Yahoo的網址作來源的，超可惜。--璃茗熒音♪ฅ^•ﻌ•^ฅ🐾$\left(Contact\right)$ 2026年3月25日 (三) 14:24 (UTC)

甚麼！？Yahoo被列入過濾器黑名單！？--Sinsyuan✍️PJTW 2026年3月25日 (三) 14:44 (UTC)

我的意思是沒那麼適合當來源了。--璃茗熒音♪ฅ^•ﻌ•^ฅ🐾$\left(Contact\right)$ 2026年3月25日 (三) 15:06 (UTC)

^[可疑] Srapoj（留言） 2026年3月25日 (三) 14:49 (UTC)

維基百科:可靠來源/布告板#香港Yahoo新聞的來源是否可靠？--璃茗熒音♪ฅ^•ﻌ•^ฅ🐾$\left(Contact\right)$ 2026年3月25日 (三) 15:03 (UTC)

我尋找連結也是需要時間的。請閣下不要妄下定論，和上次一樣。--璃茗熒音♪ฅ^•ﻌ•^ฅ🐾$\left(Contact\right)$ 2026年3月25日 (三) 15:28 (UTC)

用tabber就可以实现这功能，但是貌似这里没有这种功能，能申请开通么？--辱包专家（V • T • C） 2026年3月6日 (五) 11:20 (UTC)

@Hzt0208042508415531 tw：请明確完整地描述你的想法，不要让人玩猜谜遊戏。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2026年3月6日 (五) 14:17 (UTC)

TabberNeue扩展，制作选项卡模板，就可以按笔画顺序索引。

这个技术帖子我现在找不到了，不过确实有前人有这样的想法。--辱包专家（V • T • C） 2026年3月7日 (六) 08:33 (UTC)

@Hzt0208042508415531 tw：什麼按笔画顺序索引？tabber有多個选项卡，一個选项卡放“笔画”，其他放什麼？还是说五個选项卡分別放横竖撇捺折？还是一二三四五画？ ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2026年3月9日 (一) 07:25 (UTC)

对啊，就是笔画一二三四，部首这些。看到别人很久之前探讨过这个话题，我有回复。--辱包专家（V • T • C） 2026年3月9日 (一) 17:51 (UTC)

原来的讨论见模板讨论:Navbox#有可能编写出有分页的模板吗？

是本人记错了。这是个技术问题，我认为很好解决。--辱包专家（V • T • C） 2026年3月10日 (二) 15:42 (UTC)

Template:Isotope nav（Template:Tabs）這種？--User:What7what8🏠 2026年3月11日 (三) 14:52 (UTC)

差不多吧--辱包专家（V • T • C） 2026年3月16日 (一) 00:20 (UTC)

話說@Kanashimi：為何topic list沒辦法正確顯示Hzt0208042508415531 tw的用戶名？會顯示為「User:Hzt0208042508415531 tw」（多了一個User:），然後連結至「User:User:Hzt0208042508415531 tw」。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年3月19日 (四) 16:47 (UTC)

 已修复 因為Special:Contributions/User:Hzt0208042508415531 tw。--Kanashimi（留言） 2026年3月19日 (四) 21:32 (UTC)

⚡️ —— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年3月27日 (五) 09:36 (UTC)

各位編者好，白洲梓（讨论 | 貢獻）近期的一些編輯希望能引起注意，

1. 其中在福建省建瓯第一中学的編輯，修改了一些數值，但沒有説明原因。
2. 其中在建瓯市第二中学的編輯，修改了學校的稱呼和簡稱，沒有引用或説明原因
3. 其中在叙利亚内战对黎巴嫩的影响，修改「阿拉伯民主黨」成「阿拉伯民族黨」，説明原因是修正筆誤，但我看到兩種黨派在條目中都有。

我無法判斷此類的編輯是否正常，請各位給予關注或幫忙溝通一下，謝謝。 -Lemonaka 2026年3月10日 (二) 16:50 (UTC)

@Lemonaka，所有的编辑似乎都是没有任何来源，并且也不符合常用名称--Zyx快困死了 2026年3月10日 (二) 16:58 (UTC)

我懷疑這種編輯可能是有害的，也希望更多編者給予檢閲。 -Lemonaka 2026年3月10日 (二) 17:17 (UTC)

@shizhao 請決斷吧。 -Lemonaka 2026年3月12日 (四) 09:39 (UTC)

缺乏来源或理由令人难以接受，但目前看不出该用户虚构或意图破坏条目，似乎应该警告沟通。--YFdyh000（留言） 2026年3月12日 (四) 16:40 (UTC)

已經嘗試溝通，但該使用者不回應。 -Lemonaka 2026年3月12日 (四) 16:43 (UTC)

@Lemonaka Hi, would you consider changing the thread title to clarify that this is related to the behaviour of a user named "白洲梓", not on the article 白洲梓? MilkyDefer 2026年3月14日 (六) 15:45 (UTC)

Sure, already done by others. Thanks a lot. -Lemonaka 2026年3月15日 (日) 13:05 (UTC)

@YFdyh000@Zyx20101210
該用戶再次于米揚魯德將「庫爾德斯坦省」 改爲「胡齊斯坦省」，經查實該編輯合理。伊朗戰爭 (2026年)中將「法斯通訊社」改爲「瓦爾斯通訊社」，這一改動不具有意義。其餘編輯未見明顯問題。需提醒該用戶編輯時正確使用編輯摘要 -Lemonaka 2026年3月22日 (日) 19:26 (UTC)

通讯社似乎是手动修改地区词为大陆用法。客栈讨论中被不当转换了。--YFdyh000（留言） 2026年3月22日 (日) 19:44 (UTC)

大陆好像用的是法尔斯而非瓦尔斯--GrandCeres（留言） 2026年3月28日 (六) 07:22 (UTC)