- 為了莫內《睡蓮》走進倉敷大原美術館，最後難忘的卻是兒島虎次郎《朝顏》與館藏中的死亡題材畫作 - 2026-07-27
- 倉敷阿智神社散策，花纏守、紫藤花與從高處俯瞰的美觀地區 - 2026-07-27
- 臉書文章備份後放哪裡？把貼文搬回網站，用 3 款 WordPress 外掛保存舊文、維持版面乾淨，也能讓 Google 與 AI 找到 - 2026-07-27
最近開始看到 Facebook 陸續出現個人帳號或粉專被莫名封鎖的情況，讓我想起很久以前曾經寫過一篇關於《揮別 Facebook，讓個人帳號和粉絲專頁重新出發！》的文章，只是那時候我並沒有分享，這些從 Facebook 取回來的文字，到底要放在哪裡？
以前曾有前輩說過，Facebook 上的文章比較像草稿，部落格上的文章才是真正可以長期保存、整理與被搜尋的文章，故當時前輩建議我，可以把 Facebook 的文章搬回自己的網站裡，我也依照前被建議來執行，經過一段時間後，這個方法確實有幫助，某幾篇移轉過來的文章，帶來不錯的搜尋流量，甚至到了 AI 普及的現在，也意外成為 AI 抓取或參考的來源。
也因此，與其把文章繼續留在 Facebook 上，讓它們在演算法裡慢慢沉下去，甚至不知道哪一天會因為帳號被封鎖而一併消失，我反而覺得，如果本來就有自己的網站，或許可以考慮把 Facebook 文章搬回網站保存。
當然，把大量社群舊文搬進網站，也會帶來另一個問題，會不會讓首頁、分類頁、RSS 或電子報變得很混亂？經由前輩的建議，透過 WordPress 外掛來進行分類排除、單篇隱藏與自訂內容系統等功能設定，透過這些設定可以讓這些像草稿、日記或社群備份的文章，不出現在網站主要版面中，卻仍然可以讓 Google 搜尋到，也讓 AI 有機會讀取到。
因此我這篇文章想分享的，不是如何把網站文章同步發到 Facebook，基本上這部分也是可以透過外掛來處理的，這方面的外掛眾多，大家可以依照需求去找尋，這部分就不在這邊討論了。這篇主要想談的是：如果已經把 Facebook 文章備份下來，或開始擔心社群帳號哪天突然消失，那麼要怎麼把這些文字放回網站時，也同時維持網站版面的乾淨的這個問題
第一階段－舊文搬回網站，避免驚動訂閱者與打亂閱讀動線
我在把 Facebook 舊文搬回網站時，第一個使用的外掛就是 Ultimate Category Excluder。對我來說，它最適合使用在「大量舊文備份」這個階段。
因為我的做法不是把所有文章重新當成新文章發布，而是保留它原本的時間，假設我在 2021 年 5 月 5 日在 Facebook 發了一篇文章，那麼搬回 WordPress 時，一樣會把發布日期設定成 2021 年 5 月 5 日，畢竟我的目的只是備份，不是重新搶一次曝光度。
既然這篇文章原本就是幾年前的內容，沒必要讓它重新出現在最新文章裡，且 Facebook 文章發布時間其實跟當下人生軌跡有很大的相關連，畢竟一般來說我們發布在 Facebook 是立即性的，為此時間也成為一項很重要的記憶點。
按照這種做法，大部分舊文其實本來就不太會跑到首頁前面。只要網站文章排序是正常按照日期由新到舊排列，一篇五、六年前的文章發布之後，通常還是會待在原本年份的位置，不至於突然佔據首頁，真正的問題反而出現在其他地方。
要注意的是，即使 WordPress 文章的日期被設定在幾年前，只要是現在才第一次按下「發布」，某些與文章發布動作連動的服務，仍可能把它視為新發布的內容。而我們在整理 Facebook 舊文時，速度通常不會太慢，畢竟大多只是複製文字、補上圖片，再重新排版，勤快一點，一天甚至可能連續搬遷十來篇文章。
如果這些文章大量同時出現在網站首頁或 RSS Feed，原本只是想備份舊文，最後卻可能干擾網站原本的內容安排，甚至讓 RSS 訂閱者在短時間內看到大量舊內容，這會造成嚴重的干擾，同時讓真正重要的文章被淹沒在一堆舊文之中，進而降低點閱率，這不是我想看到的巨面，因此我當時最主要想處理的就是這件事情。
而使用 Ultimate Category Excluder 就可以整批排除舊文，它做法是以「文章分類」為單位進行排除，可以先建立一個專門存放 Facebook 備份文章的分類，再透過外掛決定這個分類的文章不要出現在哪些位置，目前可以排除的位置包括：
- 網站首頁
- RSS 資訊提供
- 日期、作者等彙整頁面
- 網站搜尋結果
我的做法是把以前從粉絲團搬回網站的文章，全部放進同一個專門設置的分類內，再透過外掛一次將整個分類從首頁與 RSS Feed 中排除。這樣在大量整理舊文時，即使短時間內連續搬回多篇內容，也能避免它們出現在首頁內容列表，或一次全部進入網站的主要 RSS Feed。
使用 Jetpack 電子報的人要另外注意，Ultimate Category Excluder 控制的是文章會不會出現在首頁、RSS、彙整頁面與搜尋結果，並不會停止 WordPress 的文章發布動作，也無法阻止所有與發文連動的服務。
因此，如果網站有使用 Jetpack 電子報，即使文章已經從 RSS Feed 排除，發布時仍可能寄送電子郵件通知，大量搬運舊文前，還是要在 Jetpack 中另外確認該篇文章已設定為只發布、不寄送電子報。
這裡之所以特別提出 Jetpack，是因為它與 WordPress 的整合程度高，使用者也相對普及，很容易讓人誤以為只要把文章排除於 RSS，就不會再寄出電子報。實際上，市面上的電子報服務很多，不同服務的觸發方式也不一樣，有些電子報會讀取 RSS，有些則直接在 WordPress 發布文章時啟動。
因此，是否會自動寄信，仍要依照自己網站使用的電子報外掛或串接方式確認。同樣地，自動分享到社群、Webhook，或其他與文章發布動作連動的服務，也可能在文章發布時被觸發，故在大量搬運舊文前，最好先檢查網站目前啟用了哪些自動化功能，不能只依靠 Ultimate Category Excluder。
這款外掛並不是所有人都一定要使用，像我這種會保留原始發布日期的做法，幾年前的文章本來就不會出現在首頁上，如果網站沒有 RSS 訂閱者，也不在意這些舊文出現在彙整頁面或搜尋結果，那麼其實未必需要特別安裝這款外掛。
但如果你的需求是大量搬回 Facebook 舊文，同時希望整批控制它們在網站上的顯示位置，那麼 Ultimate Category Excluder 仍然是很直接的做法，尤其有些人只是單純想替社群內容留下網站備份，主要閱讀與互動空間仍然放在 Facebook，並且不希望這些舊文混入網站的正式文章、搜尋結果或主要彙整頁面，這時就可以直接將整個備份分類排除。
所以對我來說，這款外掛最重要的用途，不是把舊文章完全藏起來，也不是阻止所有發布通知，而是把大量備份文章與網站的正式內容分開管理。文章依然保存在自己的網站裡，也能透過網址直接開啟，但不會混入首頁、主要彙整頁面與搜尋結果，也可以避免進入網站的主要 RSS Feed。
第二階段－新文持續增加，逐篇控制曝光位置避免干擾動線
第一階段使用的 Ultimate Category Excluder，比較適合處理一次搬回的大量舊文章。這些內容數量多，如果逐篇設定會耗費不少時間與體力；加上通常會保留幾年前的原始日期，對目前首頁與最新文章區塊的影響也較小。
因此，最有效率的做法是先把舊文集中到同一個分類，再透過 Ultimate Category Excluder 整批排除首頁、RSS、彙整頁面或搜尋結果，但當過去的舊文大致整理完成，之後開始持續把現在發布的社群內容同步回網站時，處理方式就需要改變，因為這些文章已經是現在進行式了。
假設我今天在 Facebook 發了一篇文章，今天或隔天就把它搬回網站，這篇文章的日期就是最近的日期。只要網站依照發布日期排序，它自然就可能出現在首頁、作者頁面、最新文章區塊、上一篇與下一篇導覽，甚至被主題或外掛放進相關文章與推薦內容中。
也就是說，過去的舊文雖然數量很多，但因為年代久遠，對現在網站版面的影響通常有限，然現在持續新增的社群備份文，數量雖然不多，卻會直接進入網站目前的閱讀動線，這就是第二階段需要改用 Hide Posts 的原因。
我們要知到社群發文和正式部落格文章的更新速度差很多，社群可能想到什麼就寫什麼，一天發布一篇並不奇怪，有時甚至一天會連續發布好幾篇，但正式網站文章通常需要整理資料、照片、段落與版面，一個星期能完成一篇，對許多個人網站來說已經是很難得的更新速度了。
假設正式文章一星期發布一篇，但社群備份文章一天增加一篇，幾天之後，首頁或最新文章區塊就可能被社群短文快速占滿，真正花較多時間整理的正式文章，反而會被擠到後面。對第一次進入網站的讀者來說，也可能因此產生錯誤印象，覺得這個網站主要都是日記、短文或生活紀錄，而忽略原本完整的旅遊文章與實用內容。
所以第二階段要處理的，已經不只是第一階段的「如何快速整理大量舊文章」，而是這篇社群文章我想保留，也希望它有自己的網址，甚至能透過搜尋被找到，但我不希望它進入網站原本為正式文章設計的重要位置。
這時候，以文章為單位設定的 Hide Posts，就比整個分類一起排除更適合，和 Ultimate Category Excluder 以整個分類為單位的做法不同，Hide Posts 可以在每一篇文章中單獨設定。
依照外掛提供的選項，可以控制文章是否出現在網站首頁、分類頁面、搜尋結果、標籤頁面、作者頁面、日期彙整頁面、其他彙整頁面、RSS Feed、上一篇與下一篇文章導覽、最新文章小工具，以及單篇文章頁面的部分推薦區域等，這種逐篇控制，反而很適合現在持續增加的社群備份文章。
因為這些文章通常不是一次出現幾百篇，而是今天一篇、明天一篇，或一次新增少數幾篇，數量不多，就有餘力在發布時順手完成設定。而且每篇社群文章的性質不一定相同，有些文章只是簡短生活紀錄，可以從大部分網站入口排除；有些文章內容較完整，站長可能覺得可以給比較多出現的版面；有些則可能和正式文章具有關聯，可以保留在部分分類或推薦區域。
因此，到了第二階段，比起整個分類一律使用相同設定，逐篇調整反而更符合實際需求，以我的網站來說，我通常會勾選下這五個選項：
- Hide on authors page
- Hide in RSS Feed
- Hide from post navigation
- Hide from recent posts widget
- Hide on single post page
這幾項設定的目的都很一致：社群備份文章可以存在網站裡，但盡量不要進入原本為正式文章設計的主要閱讀動線。
Hide on authors page 是不讓備份文章出現在作者文章列表中。我的網站有自我介紹與作者相關區域，讀者可以從這裡查看我近期發布的文章，但當讀者進入作者頁面時，我希望優先展示的是較完整、真正想推薦給讀者閱讀的內容，而不是從 Facebook 搬回來的短文、生活紀錄或臨時感想。
這並不是表示社群文章沒有價值，而是兩種文章的閱讀情境不同。社群文章比較像即時紀錄，正式文章則通常有更完整的主題、資料與閱讀結構，因此作者頁面這類重要入口，我仍希望主要保留給正式內容。
Hide in RSS Feed 則是將社群備份文章從 RSS Feed 排除。社群文章的發布頻率通常遠高於正式文章，如果每一篇備份文章都進入 RSS Feed，訂閱者可能在短時間內看到大量短文或生活紀錄，原本穩定的正式文章更新節奏也會被打亂。
不過需要注意，排除 RSS 不代表一定能阻止所有電子報或發布通知。不同電子報服務的觸發方式不同，有些讀取 RSS，有些則直接監聽 WordPress 的文章發布動作，因此仍要另外確認自己網站使用的電子報與自動化服務設定。
Hide from post navigation 是我自己很在意的一項設定，我的網站主題有上一篇、下一篇的文章導覽功能。讀者看完一篇正式文章後，可以直接繼續閱讀前後發布的內容，例，讀者剛看完一篇完整的日本旅遊文章，文章底部的下一篇卻突然跳到一篇只有幾十個字的 Facebook 日常備份，整個閱讀節奏就會顯得很斷裂。
因此，我會勾選 Hide from post navigation，避免社群備份文進入上一篇、下一篇的文章導覽，希望讀者讀完一篇正式文章後，下一個被推薦的內容，仍然是另一篇值得繼續閱讀的正式文章，而不是剛好依照發布日期，夾在兩篇文章之間的社群短文。
Hide from recent posts widget 則是避免社群備份文章占用「最新文章」的位置，很多 WordPress 網站會在側邊欄、頁尾或首頁放置最新文章小工具。我的網站以前也有類似的展示區域，雖然現在已經移除，但我仍會保留這項設定。
原因很簡單，社群發文速度實在比正式文章快太多，假設正式文章一星期發布一篇，但 Facebook 備份文章一天增加一篇，過沒幾天，最新文章區塊就可能全部被社群備份文占滿，真正花費較多時間完成的文章，反而很快被擠下去，對剛進入網站的訪客來說，也可能只看到一整排生活短文，進而忽略網站原本較完整的內容。
Hide on single post page 這個名稱乍看之下，很容易讓人誤以為是把文章本身隱藏起來。依照外掛說明，它主要是避免這篇文章出現在單篇文章頁面中的 recent posts、related posts，以及部分小工具或推薦區域，現在很多 WordPress 主題或外掛，會在文章底部自動顯示最新文章、相關文章、「你可能也喜歡」或其他推薦內容。
這些位置對網站內部導流很重要，因此我同樣希望優先保留給正式文章。我不希望 Facebook 備份文只是因為日期、分類或演算法條件，就被放到正式文章底下的推薦區域中，勾選這項設定，可以進一步降低社群備份文章進入網站推薦內容的機會。
不過，這類選項能否完全控制所有相關文章區塊，仍要看網站主題與推薦外掛的實際運作方式，如果某個推薦功能使用自己的查詢邏輯，Hide Posts 未必能影響所有區塊，設定後仍需要實際檢查前台結果。
對我來說，兩個階段最大的差別，不只是使用不同外掛，而是文章本身的狀態不同，可以這麼說：第一階段追求的是效率，第二階段追求的則是精準。
第一階段處理的是過去多年累積的大量舊文。這些文章數量很多，沒有體力逐篇設定，通常也會保留舊日期，對現在網站版面的影響較小，因此適合用分類整批處理。
第二階段處理的則是現在與未來陸續增加的社群文章。這些文章每次新增的數量不多，有餘力逐篇調整，但日期接近現在，很容易出現在網站各個位置，並實際影響首頁、最新文章與整體閱讀動線，因此更適合逐篇精細控制。
我自己的原則很簡單：文章可以留在網站裡，但網站的重要閱讀位置，還是優先留給正式文章。
如此一來，從 Facebook、Instagram 或其他社群平台搬回來的文字，仍然可以保有自己的網址，可以長期保存，也有機會透過搜尋被找到，同時對一般讀者來說，它們不會大量出現在作者頁、RSS、最新文章、上一篇與下一篇導覽，或相關文章推薦中。
這樣既能持續保存社群上的生活文字，也能避免現在進行式的社群文章干擾網站版面，讓網站維持原本清楚而穩定的閱讀動線。
第三階段－備份文章日記化，分開管理日記與正式文章標籤
第三階段使用的 Custom Post Type UI，我自己覺得算是比較進階的做法。相較於前面兩款外掛，如果沒有和我類似的內容管理需求，其實不一定需要做到這一步。
一開始，我只是把過去累積在 Facebook 上的文章搬回網站保存，後來沒有繼續經營 Facebook，原本會發布在社群上的生活文字，也逐漸改成直接寫在網站裡。這些內容因此不再只是從 Facebook 搬回來的備份文章，而是網站日記與生活紀錄的一部分。
當這類文章持續增加後，我遇到的問題也不再只是「要把文章隱藏在哪些位置」，而是日記和正式文章原本共用同一套文章、分類與標籤系統，管理久了很容易混在一起。因此到了第三階段，我希望進一步把兩種內容分開管理，讓日記擁有自己的文章類型與標籤系統，不再和正式文章共用完全相同的內容架構。
另外，日記和正式文章的命名方式也不太一樣。正式文章通常有明確主題，標題與網址可以圍繞同一件事情撰寫，生活紀錄往往同時包含一天之中發生的多件事情，例如去了某間店、網站流量出現變化、工作上遇到一些狀況，或只是留下幾句當天的想法。
這些內容彼此未必有直接關聯，很難用一個標題完整概括，如果硬是挑其中一件事情當標題，再把標題放進網址裡，反而容易讓網址只代表文章中的其中一小部分。因為這篇日記真正記錄的，不只是某一件事，而是那一天發生的各種片段，所以後來我的做法很簡單，就是直接使用日期作為網址，於是網址通常就是 https://yanshoto.com/2026-07-23/ 這樣。
既然這些內容的本質是日記，用日期來做為網址是一種更直觀的做法，而且我本來就沒有打算讓生活日記承擔太多搜尋流量，網站的主要內容仍然是完整整理過的正式文章，沒有必要為了 SEO，刻意讓日記的標題、關鍵字與網址互相對應。
因此對我來說，日期網址最重要的用途不是排名，而是辨識。文章顯示的發布日期日後可以調整，但某一年、某一月、某一天只會出現一次，只要網址中保留年份與日期，我之後看到網址，就能立刻知道這篇內容記錄的是哪一天發生的事情。
除了用年份與日期管理網址，我也會另外替每篇日記加入日期 Tag。，例如 6 月 5 日，就建立一個「0605」的 Tag。之後只要點進這個 Tag，就可以看到不同年份裡，所有曾經在 6 月 5 日留下的紀錄，這樣的整理方式，有點像 Facebook 動態回顧「我的這一天」這個功能。
雖然自己的網站不一定會主動跳出提醒，但只要點進同一天的 Tag，就能把不同年份的生活重新串在一起。因此，年份與日期網址負責辨識「這是哪一天的日記」，日期 Tag 則負責整理「歷年的同一天發生過什麼」，這也是我一定需要日期 Tag 的原因。
只是這套做法很快就會遇到另一個問題：一年有 365 天，如果每一天都建立一個日期 Tag，光是日期就可能出現 365 個標籤，而且這還不包含其他自己需要的日記標籤，像我自己可能還會加上網站流量、網站調整、工作紀錄、旅行準備、生活紀錄等標籤，方便自己之後快速找到相關文章，如此一來光是日記需要的標籤量會非常的大。
雖然使用網站搜尋功能也可以找到內容，但我自己還是覺得用 Tag 比較直觀，畢竟 Tag 本來就是拿來把有共同特徵的文章整理在一起，只要點一下，就能直接看到相關紀錄。
問題是，當這些日記用的 Tag 全部和正式文章混在一起之後，WordPress 後台的標籤數量直接龐大到我無法整理跟快速瀏覽。而且日記用的標籤和正式文章的標籤，本來就是兩種完全不同的用途，正式文章可能會使用東京、京都、和菓子、文具、交通票券這類標籤；而日記裡卻可能出現 0505、0605、網站流量、文章修改、缺照片等管理用途的標籤。
當這些全部混在一起之後，不只是自己後台管理很麻煩，前台的讀者如果點進 Tag 頁面，也可能看到一堆原本只是用來整理日記的相關 Tag，無助於讀者搜尋文章，故我才使用 Custom Post Type UI，來替這些日記文章建立另一套獨立的分類與標籤系統。
簡單來說，就是讓正式文章使用自己的 Tag，而日記短文則有另一套 Tag，兩邊分開管理。這樣我自己在整理日記時，可以使用大量日期 Tag 與其他管理標籤，這部分不會出現在前台，前台只會有正式文章的 Tag ，讀者點擊後看到的仍然是旅遊、店家、文化或其他主題內容，不會突然混進大量生活日記。
使用這套外掛，這對我來說最大的好處，就是前台和後台可以分開處理，讀者看到的是整理過的正式內容，而我自己則可以在後台觀看這套生活紀錄的 Tag。而且這套獨立的標籤系統也不一定只能用來記日期，也可以拿來管理自己的文章流程，例如有些文章可能缺照片、等待補充資料、需要重新整理，或者預計之後改寫成正式文章，這些狀態也可以透過獨立的分類法來管理。
不過這部分真的很看個人需求，如果只是把 Facebook 舊文搬回網站保存，不希望它們出現在首頁或最新文章區域，那麼前面介紹的兩款外掛通常就已經足夠了。
但如果平時就有替備份文章加上 Tag，或像我一樣會在網站裡寫日記、生活紀錄，甚至想利用日期 Tag 回顧歷年同一天的內容，那麼如何整理 Tag 就會變得格外重要。這種情況下，將不同用途的 Tag 分類管理，雖然前期需要花一些時間設定，長期來看卻是一項很值得的投資，不但能避免標籤愈堆愈亂，也能讓日後查找與回顧內容方便許多。
第四階段－社群生活回到網站，讓舊文字再次被搜尋與看見
這些從 Facebook 搬回來的舊文之所以重要，不只是因為它們曾經被發布過，而是因為它們本來就是生活軌跡的一部分。那些文字裡有生活記憶、有當時的狀態，也有很多現在回頭看，可能只是隨手寫下的一篇廢文，但對當時的自己來說，卻是真實存在過的一天。
只是這些記憶長期都被放在 Facebook 手中，經過這次大規模鎖帳號之後，我相信很多人都會更有感，尤其是看到有些經營十幾年、二十幾年的帳號，突然之間就被鎖住，甚至整個帳號都拿不回來的絕望，那種感覺應該只有真正經歷過的人，才會切實明白。
所以如果有些社群上文章很重要，或者它本來就是我們生活的一部分，除了單純備份之外，其實也可以再找一個地方把它備份起來，至少在未來又發生刪帳號悲劇時，比較不會那麼絕望，畢竟它一直保留著。同時也可以讓自己可以在多年後重新整理文章時，成為回顧自己的線索。
像我這次在整理舊文時，就會突然想起：原來那一年我做過這件事，原來那一天發生過這件事，原來那時候我的身體狀況其實就一直不太好。很多事情如果沒有留下文字，可能早就被時間沖淡了；但只要當時有記錄下來，幾年後再回頭看，就會重新拼回一段已經忘記的生活。
另一個讓我覺得舊文值得保存的原因，是有些文章你以為不重要，但在現在這個充滿 AI 文的年代，反而可能出乎意料地變成很重要的文字或內容。
之前從粉專備份過來的一篇文章，老實說大概也不到三十個字，當初只是很隨手地留下紀錄，結果後來竟然讓 AI 搜尋抓進去。這件事有時候想起來也有點微妙，自己認真寫了七八千字的文章，流量可能還不如那一篇三十個字的短文。
這也提醒我，文字的價值有時候不是寫下當下就能判斷的，有時候這些舊文也會幫到未來的自己，像我曾經在搜尋某些資訊時，意外搜尋到自己的文章，才發現原來我以前就找過資料，一下就喚醒我所有記憶了，只是每每這時候就會有點感概就是，需要資料來救援，結果最後能搜索到的居然是自己。
也有一些日記文章或備份文章，後來卻因為流量異常地高，讓我不得不重新注意它，像之前隨手寫的「保國衛民漫畫包廂」就是經典例子，待改寫成正式文章後，現在是我網站流量最高的文章之一。這些經驗都讓我覺得，有些舊內容其實可以作為未來文章的參考和種子。
在數位平台越來越發達的現在，不管是 Threads、Instagram，還是 Facebook，多少都有對外開放，搜尋引擎也有機會找到部分內容，但問題是，這些平台再怎麼開放，終究不是自己能完全掌控的地方，帳號掌握在別人手中，你也很難確定什麼時候會突然失去它。
不是說乖乖不踩官方的雷點就會平安無事，有時候惡意檢舉，或是像這次大規模誤判都會導致自己的帳號消失，因此與其把所有內容都放在社群平台上，不如趁自己現在還有時間，慢慢把值得保存的文章搬回自己的網站裡，特別是本來就有網站的人，這其實是一個很適合整理舊文的方法。
我也知道，現在有些 SEO 社群討論會提醒，網站如果放入太多與主要主題無關的內容，可能會讓網站定位變得模糊，尤其是大量使用 AI 快速生成、缺乏實際經驗與閱讀價值的文章，更可能落入所謂的「規模化內容濫用」。不過我覺得，這類為了增加文章數量或搶占搜尋關鍵字而大量產出的內容，和自己多年來真實寫下的生活紀錄，性質並不完全相同。
只要是自己的生活記憶，未來總有一天可能會不自覺地被帶進其他正式文章裡，像我自己在寫文章時，就常常會突然想到，以前好像有寫過這件事。這時候回頭去找日記或舊文，就可以把那段記錄重新拉進現在的文章裡，它可能一開始只是備份、日記或廢文，但幾年後，卻可能成為另一篇正式文章的重要補充。
所以我會覺得，只要是人真正寫出來的東西，它在未來某一天，總有可能重新和其他內容連接起來，只是不知道會是什麼時候，這也是我把 Facebook 文章搬回網站保存的原因。
它不是要取代社群，也不是要把每一篇舊文都變成正式文章，而是在這個被社群平台綁住的年代，替自己的文字多留一個可以安放的地方，就算只是一篇廢文，在現在大家越來越少好好用文字記錄生活、表達想法的時代裡，我仍然相信它有一定的保存價值，因為那不只是內容，而是某一天的自己，確實曾經留下來的痕跡。
小結－把臉書文章帶回網站，也是替自己的文字留下新去處
我會想寫這篇文章，主要是因為最近又看到 Facebook 個人帳號或粉絲專頁無預警遭到封鎖的情況。對很多人來說，Facebook 不只是一個社群平台，也是累積了十幾年，甚至二十幾年生活紀錄的地方，一旦帳號突然消失，不見的不只是幾篇貼文，而是過去的照片、文字、創作紀錄、生活片段，甚至是一段很長的人生軌跡。
我以前曾經寫過 Facebook 文章備份的相關內容，但備份其實只是第一步。文章下載下來之後，如果只是放在硬碟或雲端資料夾裡，雖然比較安全，卻很少會再被打開，也不容易搜尋、整理或重新使用，後來有前輩建議我把 Facebook 文章搬回自己的網站。
實際整理之後，我才發現，這些看似零散的舊文，並不一定只能停留在「備份」的狀態。有些從粉絲專頁搬回網站的文章，後來帶來了不錯的搜尋流量，也有一些當初覺得不起眼的短文，在 AI 搜尋逐漸普及之後，反而意外被找到或成為參考資料。
這也讓我重新意識到，文字的價值不一定能在寫下當下立刻判斷。某篇文章現在看起來可能只是生活紀錄、隨手感想或一份備份，幾年之後，卻可能成為自己重新回想某件事情，或讓別人找到某段資訊的入口。
不過，把 Facebook 舊文搬回網站，也不代表要把所有內容直接混進原本的部落格架構中。大量舊文如果同時出現在首頁、分類頁、RSS、電子報或最新文章區塊，很容易打亂網站原本的更新節奏，也可能讓讀者與訂閱者感到困擾。
因此，這篇文章真正想分享的，不只是如何把社群文章搬回 WordPress，而是如何在保存內容的同時，讓它們與正式文章分開管理。對我來說，這是一種折衷的做法。這些文字不必繼續被困在 Facebook 裡，也不需要全部改寫成正式的部落格文章。
它們可以保有自己的網址，能被 Google 搜尋、整理與回顧，卻不必占據網站首頁或主要閱讀位置，這樣既能維持網站原本清楚的版面，也能讓過去寫下的文字保存在自己能掌握的空間裡，即使有一天社群平台發生變化，這些內容依然存在，不會隨著帳號或平台一起消失。
＊本文文字皆由筆者（yanshoto.com）原創撰寫，著作權歸作者所有。未經授權，請勿全文轉載、重製、改作、重新發布或作為商業用途，感謝您的理解與尊重。
相關討論文章延伸
- 不該把 Facebook 當作朋友的 5 大原因
- 把握 3 項重點，讓免費平台也能有自架網站的優勢
- 揮別 Facebook，讓個人帳號和粉絲專頁重新出發！學會如何完整下載和備份貼文資料，自己的資料自己掌握
