如何建立對 SEO 友好的支持知識庫：可擴展文檔解決方案的完整指南

已發表: 2016-10-26

一旦您的初創公司的用戶群增長，支持就成為您業務的基本組成部分。建立一個可靠的知識庫解決方案是一項重要的長期投資，如果做得好，有望通過減少支持負擔、擴大您網站的 SEO 範圍和產生否則不會獲得的新線索來獲得回報。

這是面向開發人員的全面的技術分步指南。如果您不是開發人員，您可能應該將這篇文章發送給您的 CTO。他/她會為此感謝你。

TL;DR：我們最終使用 WordPress 為我們的貨幣化平台 Freemius 構建並發布了基於降價的半靜態知識庫。我在這里分享我們研究的完整食譜；為什麼我們選擇 WordPress 而不是 SaaS 解決方案和靜態生成器；我們是如何做到的（包括所有代碼自定義和服務器級配置），我們學到了什麼，以及您如何復制該過程以節省寶貴的時間，並設置您自己的閃電般快速、可擴展、可持續、安全和半用於您自己的插件、主題或任何其他數字產品的靜態 KB（知識庫）。

這個 15 分鐘的指南將為您節省 44 小時（我們使用時間跟踪）的研究、定制、測試和優化。如果您還沒有建立自己的文檔中心，只需將此頁面添加為書籤，並在適當的時候回來。

你準備好了嗎？開始了。

動機
您應該在文檔解決方案中尋找什麼？
1. 可擴展且耐用
2. 用戶友好的後台
3. 可持續的
4. SEO優化
5. 品牌兼容
選擇正確的文檔平台很難！
- 知識庫軟件即服務
- 靜態知識庫
- WordPress 支持的知識庫
為什麼我們沒有選擇 Help Scout Docs 或任何其他 SaaSy 知識庫
為什麼我們選擇 WordPress 而不是靜態站點生成器作為我們的知識庫
為什麼我們選擇 weDocs WordPress 插件作為我們的知識庫？
安裝和自定義 weDocs 文檔解決方案
- 添加麵包屑豐富片段元數據
- 自定義知識庫 URL 結構（永久鏈接）
- 將漂亮的主頁添加到 weDocs 知識庫
- 使 weDocs 移動友好/響應迅速
使用 Markdown 代替 HTML 富編輯
- 選擇和安裝 Markdown WordPress 插件
- 添加 YouTube 和 Vimeo Markdown 支持
- 添加漂亮的標註簡碼支持
- 為 Pretty Code 添加 SyntaxHighlighter
我們如何使我們的 WordPress 知識庫變得超快？
- 添加磁盤權限
- 啟用緩存
- 配置服務器級緩存
- 添加 CDN
我們如何自定義 KB 搜索來服務緩存數據？
我們如何保護我們的 WordPress 知識庫？
輪到你了

動機

自 Freemius 早期以來，文檔一直在我們的 TODO 列表中。話雖如此，當產品處於早期階段時，急於記錄它是沒有意義的。重點應該是驗證假設和快速迭代，直到您獲得令人滿意的產品市場契合度。大約一年半前，我們開始使用 Freemius，我們終於覺得是時候優先考慮文檔了。

您應該在文檔解決方案中尋找什麼？

在急於解決之前，我想制定一些計劃。因此，我制定了以下要求列表：

可擴展且耐用

與任何其他基於 Web 的解決方案一樣，它必須能夠隨著我們的流量進行擴展，同時保持相同的性能。當知識庫超過十幾篇文章時，還必須繼續毫不費力地找到答案。換句話說——很好的搜索！

用戶友好的後台

對於團隊中的任何成員，無論他們是否是開發人員，添加和編輯文檔文章都應該很容易。

可持續的

沒有什麼可以天長地久。設計趨勢在不斷變化，技術也在不斷發展。因此，修改知識庫的 UI 應該相對容易，並且在極端情況下，可以輕鬆導出數據並完全遷移到不同的系統。

SEO優化

文檔就是內容。與您的博客文章不同，知識庫文檔僅關注您的產品。你的關鍵詞。這是在您銷售的任何產品中增強您的 SEO 權限的好方法。

此外，當用戶搜索某些東西時，通常的習慣是立即使用搜索引擎。這比打開您的網站、查找知識庫/幫助中心/文檔鏈接，然後才搜索解決方案更容易。因此，您最好確保您的文檔內容對搜索引擎可見並針對它們進行了優化，如果您針對的是英語市場，尤其是谷歌。

品牌兼容

知識庫的外觀和感覺應該與我們公司的設計語言和品牌相匹配。這包括顏色、字體、頁眉和頁腳樣式等。

選擇正確的文檔平台很難！

按照我的自然發現流程，我去向谷歌尋求建議。這一次，谷歌沒有幫助。搜索結果是壓倒性的。不僅市場上有如此多的選擇，而且解決方案本質上是不同的。

谷歌沒有幫助。市場上有很多選擇，解決方案本質上是不同的。Tweet

知識庫軟件即服務

有由 Help Scout Docs 和 Zendesk Help Center 等服務台公司提供支持的指定知識庫軟件解決方案。

靜態知識庫

靜態站點生成器正變得越來越流行。如果您不熟悉這個概念，一般的想法是大多數網站幾乎都是靜態的（包括您的 WordPress 博客），並且沒有真正的理由運行像 WordPress / PHP / MySql 這樣的耗儘後端堆棧。相反，將繁重的工作轉移到一個預部署引擎上，該引擎將生成靜態 HTML 頁面，這些頁面可以託管在 CDN 上，甚至無需接觸您的服務器。它具有成本效益、可擴展性和安全性。

那裡有數百個生成器，並且像 Jekyll 和 Hugo 這樣的引擎在核心開發者社區中被高度採用（這是有充分理由的！）。

WordPress 支持的知識庫

我在 WordPress.org 存儲庫中發現了 20 多個免費的知識庫插件，另外十幾個 CodeCanyon 和 Google 上的付費文檔插件，以及另外十幾個幫助中心主題。

感覺一頭霧水？我肯定做了¯\(°_o)/¯

正如你所看到的，方式，方式太多的選擇。我決定嘗試另一種策略——徵求我信任的人的建議。我是一個名為“銷售 WordPress 產品”的 Facebook 小組的成員，我的許多朋友和領先的 WordPress 產品人員都是其中的一員。我很確定他們中的 90% 都在我之前處理過同樣的挑戰，所以絕對值得一試。

在我上傳我的問題之前，我做了一些搜索，發現了一個 2015 年的帖子，由 WP Mayor 的 Jean Galea 開始，它提出了完全相同的問題：

驚人的！我心想。然後我開始閱讀答案……

Adrian Labos 正在使用 Zendesk Help Desk
Pippin Williamson (Pippin Plugins) 和 Adam Pickering (Astoundify) 正在使用Help Scout Docs
Phil Derksen 正在使用帶有 KnowHow 主題的 WordPress
Dejan Markovic (Hype Social) 正在使用帶有 weDocs 插件的 WordPress
Devin Walker (WordImpress) 正在使用帶有 CPT 和 ACF 插件的 WordPress。
構建 DocPress 主題的 Ahmad Awais 說，“隨著產品數量的增長，使用 WordPress 維護文檔站點變得低效”，現在他正在使用 Jade 模板引擎構建靜態知識庫。
Tom Hemsley（Mega Menu Plugin）推薦使用帶有 Heroic Knowledge Base 插件的 WordPress。
還有另外三個關於他們的作者的其他 WordPress 插件的回复，這些都是該組的一部分。

如您所見，根本沒有共識。不幸的是，這不是很有幫助。

該死的——是時候進行一些研究了……

提示：作為旁注，如果您是 WordPress 領域的產品人員，我強烈建議您申請這個小組。

訂閱並獲取我們的免費副本

WordPress 插件商業書籍

究竟如何在訂閱經濟中創造繁榮的 WordPress 插件業務。

感謝訂閱！

- 我們剛剛將您的“The WordPress Plugin Business Book”副本發送到.

您的電子郵件中有錯字嗎？單擊此處編輯電子郵件地址並再次發送。

為什麼我們沒有選擇 Help Scout Docs 或任何其他 SaaSy 知識庫

我是 Help Scout 的粉絲，我們將它們用於我們的支持票務系統。事實上，我是創始人的朋友。早在 2011 年，我們在波士頓的 Techstars 加速器計劃中參加了 2 台辦公桌並一起工作了 4 個月。那是在幫助偵察員只有丹尼、傑瑞德和尼克的時候。

Docs 是一個非常可靠的文檔解決方案，可能是最簡單快捷的方法。它的可定制性也令人驚訝。但與其他 SaaS 平台一樣，它也存在 SEO 缺陷。

1. 在搜索排名方面，在子目錄中設置知識庫或任何其他內容仍然明顯優於在子域中。 MOZ（世界領先的 SEO 公司）的創始人 Rand Fishkin 有一個 2015 年的精彩視頻，其中包含討論該主題的真實用例。

不幸的是，由於 DNS 區域文件的工作方式，無法將 CNAME 設置到子目錄。

為了確保我沒有錯過任何解決方法，我聯繫了 Help Scout 支持團隊，以下是我收到的回复：

“討厭帶來壞消息，但沒有辦法將 Docs 放在子目錄中。我們有一個用於 Docs 的 API，可讓您導出您的網站並自行託管它，但您必須重建一些外觀和功能：http://developer.helpscout.net/docs-api/
如果您仍想使用 Docs 並將其作為子目錄，恐怕這將是唯一的解決方案。

2. 由於前面的原因，我沒有檢查其他解決方案，但特別是Help Scout Docs ，不包含用於麵包屑和搜索的 Rich-Snippets 元數據。

這是 Google 的 SERP（搜索引擎結果頁面）上Help Scout Docs的結果：

這是包含麵包屑豐富片段元數據的頁面的結果：

這是具有搜索豐富網頁摘要元數據的頁面的結果：

我不會深入探討該主題，但總的來說，豐富片段元數據有助於搜索引擎更好地了解您網站的內容及其結構。世界領先的搜索引擎：谷歌、雅虎和必應；可以將這些數據轉化為提高搜索點擊率（點擊率）的視覺效果。底線——你會得到更多的流量。

我還聯繫了 HeroThemes 的聯合創始人 Chris Mooney，這是一家專注於知識庫解決方案的公司，他確認 SEO 是客戶遷移到他們的本地文檔解決方案的主要原因之一。

只是為了強調您可以從編寫良好的文檔中獲得的 SEO 價值的重要性，我想分享一個簡短的故事。 2011 年，我遇到了 WiX 客戶解決方案副總裁 Elad Eran。 Eran 自豪地解釋說，他們的知識庫軟件和支持論壇是幫助 WiX 在 Google 上排名靠前並獲得免費、高質量、有機流量的主要催化劑之一。

知識庫軟件和支持論壇是幫助 WiX 在 Google 上排名靠前並獲得免費、高質量、有機流量的主要催化劑之一。

如果它對 WiX 有好處，它應該對我們有好處

為什麼我們選擇 WordPress 而不是靜態站點生成器作為我們的知識庫

使用 Jekyll 這樣的引擎實現靜態的主要好處是速度、可擴展性和安全性。

我們可以用 WordPress 獲得那些嗎？答案是——幾乎。

由於文檔頁面是靜態的（搜索除外），我們可以輕鬆安裝幾十個免費的 WordPress 緩存插件之一，配置 Nginx 直接從磁盤提供緩存文件，同時跳過 WordPress 引擎，還可以使用免費的 CDN 服務，如CloudFlare 將我們的文件分發到全球不同的數據中心。這聽起來可能很複雜，但實際上並非如此，我很快就會解釋一切。

這將使我們的文檔前端變成絕對靜態的。它將擴展得很好並且會超快（因為它是靜態的）。哇！哇！

在安全方面，沒有什麼是完美的，但是，我們可以使用一些免費的插件和一些服務器級別的配置來採取一些基本的預防措施，這將降低 99.9% 的攻擊機會。稍後我將明確討論這一點，包括所有成分。

另一方面，我們團隊的靜態方法的缺點是：

作為一個團隊，我們將必須獲得新的技術技能，建立一個額外的開發環境，並有一個持續的部署過程，以確保添加或編輯文件不需要開發人員的干預。這絕對是可行的，但需要時間。
搜索（大部分）是一種動態功能，所以如果我們使用靜態，我們將不得不實現一些 RESTful API 或集成像 Algolia 這樣的第三方搜索服務。另一個令人頭疼的問題。
版本控制不是 CMS。儘管我很喜歡 GitHub 和 BitBucket，但它們對於不精通技術的人來說可能會很可怕。儘管我們所有的團隊成員都是他們背景的開發人員，但這種情況在未來可能會改變。

提示：值得一提的是，在我的研究過程中，我發現了一個名為 Prose.io 的漂亮項目，它提供了對 GitHub 和 BitBucket 文件的簡單所見即所得內容編輯。

總而言之，我們可以在不失去 WordPress 的任何靈活性的情況下獲得靜態網站的大部分好處，保持用戶友好的 CMS 編輯器並在沒有持續部署過程的情況下獲得實時編輯。

為什麼我們選擇 weDocs WordPress 插件作為我們的知識庫？

如前所述，我已經看到了至少 30 個知識庫的 WordPress 插件和主題。

由於我們正在運營一家初創公司，因此評估所有這些是不可行的。因此，讓我們嘗試消除。

知識庫主題已發布！

我們選擇不使用任何文檔主題，因為它們中的大多數使用文檔文章的默認post對象和category分類法。如果您僅為您的知識庫應用程序設置專用 WordPress 實例，則此解決方案可以工作。如果您希望將所有網站（包括您的博客）安裝在同一個 WordPress 上，那麼由於內容類型混合，事情可能而且可能會變得一團糟。

是的——我們現在只有另外 20 個插件要測試……

我測試了四個不同的免費插件：

知識庫 CPT
WP知識庫
WP 幫助
微文檔

很快我發現他們都利用 WordPress CPT（自定義帖子類型）和標籤和類別的自定義分類法。主要且唯一顯著的區別在於數據結構的層次結構。

知識庫 CPT 和 WP 知識庫是平的。與博客文章一樣，也有類別、標籤和文章。無法將文章與父文章相關聯。

因此，帶有這些插件的知識庫的結構將是作為部分的類別，作為文檔的帖子。

 第一類
↳ 文件 1
↳ 文件 2

第 2 類
↳ 文件 3
↳ 文件 4

這種結構的好處是您可以將文檔與多個類別相關聯，並使其顯示在多個部分下。

 第一類
↳ 文件 1
...
第 2 類
↳ 文件 3
↳ 文件 1

另一方面，WP Help 和 weDocs 的文章結構類似於頁面。每個文檔都可以作為父文檔與任何其他文檔相關聯。但是，它只能與一個父級相關聯（而不是與一個類別相關聯）。

 文件 1
↳ 文件 2
↳ 文件 3
↳ 文件 4
↳ 文件 5
↳ 文件 6

這種結構有兩個好處：

它更有條理。它迫使您思考最適合添加文檔文章的位置。
類別沒有特定的“順序”。因此，沒有開箱即用的方式來組織類別，就像使用具有menu_order屬性的帖子一樣。

上述原因正是我們決定使用分層插件的原因。

太好了——現在我知道了我們的文檔所需的數據結構類型。

然後我花時間閱讀了兩個高級插件——wpDocs（WP Knowledge Base 的專業版）和 Heroic Knowledge Base。兩者在視覺上都令人印象深刻，但是……

我找不到這兩個高級插件和免費插件之間的任何有意義的區別。
這兩個插件都使用平面數據結構，我們決定不使用。

所以是的——可能還有另外 10 個插件我什至沒有看過，但模式很清楚。

由於以下幾個原因，我們決定使用 weDocs 而不是 WP Help：

weDocs 的管理設置拖放 UI 是現代的、用戶友好的和視覺上引人注目的。
WP Help 不附帶文檔的自定義分類。這意味著類別和標籤不是開箱即用的。
WP Help 根本不支持麵包屑。
weDocs 附帶了一組自定義模板，這些模板可以立即使文檔看起來不錯（顯然需要一些 UI 自定義）。
weDocs 有一個連續的 UI 流程。在每篇文章的末尾，您可以導航到下一篇文章。

讓我們繼續有趣的部分——實現……

安裝和自定義 weDocs 文檔解決方案

要開始使用，請直接從 WordPress.org 存儲庫下載並安裝 weDocs：
https://wordpress.org/plugins/wedocs/

現在是時候進行一些自定義了：

添加麵包屑豐富片段元數據

由於我們不想更改實際的插件（如果可能的話），我們使用了 weDocs 模板和主題的 functions.php 來覆蓋默認的麵包屑渲染。

將/wedocs/templates/single-docs.php複製到/your-theme/wedocs/single-docs.php 。
將以下代碼添加到主題的functions.php文件中：
打開/your-theme/wedocs/single-docs.php並將對wedocs_breadcrumbs()的調用替換為freemius_wedocs_breadcrumbs() 。
由於我們還將麵包屑的 HTML 結構修改為無序列表 ( <ul> ) 以獲得更好的語義，因此將以下 SASS 代碼添加到您的主題中：

要完成 Rich Snippets，您需要將以下代碼添加到您的<body>標記中：

<body<?php if ('docs' === get_post_type()){     echo ' itemscope itemtype="http://schema.org/WebPage"'; } ?>>

自定義知識庫 URL 結構（永久鏈接）

weDocs 附帶以下默認永久鏈接結構：
your-site.com/wordpress-root/docs/

我們希望將我們的文檔放在 freemius.com/help/documentation/ 上，在搜索文檔時應該在 SEO 中排名更好。我們還希望保留“幫助”頁面以在未來添加幫助中心，以便我們可以使用 URL 結構，例如/help/faq/用於常見問題解答頁面和/help/forum/用於論壇。

我們可以通過在插件代碼中修改docs CPT 的重寫規則來輕鬆實現這一點。但由於我們想避免更改插件的代碼，我們想辦法在主題的functions.php文件中間接地做到這一點：
此外，我們還添加了對文章摘錄（下一次自定義需要）、文檔作者、自定義字段和頁面屬性的支持。 重要提示： weDocs 默認為多產品知識庫構建。因此，如果您想擁有/help/documentation/的結構，請確保您在後台創建的頂級 Doc 稱為 Documentation（slug 必須是documentation ）。

將漂亮的主頁添加到 weDocs 知識庫

默認情況下，weDocs 附帶一個短代碼，可以幫助您創建一個如下所示的主頁：

還不錯，但我個人更喜歡Help Scout Docs生成的佈局：

它提供了關於每個部分的簡短描述，並且在視覺上對我來說更具吸引力。首先，讓我們通過將docs-header-main.php和docs-sections.php添加到/your-theme/wedocs/文件夾來創建 PHP 模板。您可以在以下要點中找到代碼：https://gist.github.com/vovafeldman/adbf1c071a08b7565df11d709b2f1240 如果您深入研究docs-header-main.php文件的代碼，您會注意到我也潛入了搜索富片段元數據。現在，由於/help/documentation/文章只是知識庫中的另一篇文章，WordPress 將使用的默認模板是/wedocs/single-docs.php 。因此，我們需要將以下代碼片段添加到該文件的頂部，以在未設置文章的父級時加載新的部分模板：

if ( empty( $post->post_parent ) ) {
  wedocs_get_template_part( 'docs', 'header-main' );
  wedocs_get_template_part( 'docs', 'sections' );

  return;
}

使 weDocs 移動友好/響應迅速

不幸的是，weDocs 沒有提供響應式 CSS 規則。以下是它在 weDevs（weDocs 的開發者）知識庫中的樣子：

我不打算深入研究 CSS，但一般來說，我們添加了以下媒體查詢：

隱藏麵包屑。
使用漂亮的填充使內容全寬。
將導航側邊欄和搜索移到底部，就在頁腳之前。

結果如下：

以下是部分頁面的樣子：

偉大的！我們完成了 weDocs 定制。

使用 Markdown 代替 HTML 富編輯

知識庫的初始要求之一是可持續性——能夠輕鬆更改設計和潛在的平台（還記得嗎？）。使用 HTML 富內容編輯是一把雙刃劍。一方面，它非常靈活，可以根據需要自由定制內容樣式。另一方面，這種結構的缺乏允許每個內容作者為所欲為。這是不可持續的，使設計更改變得複雜，遷移變得更加困難。例如，使用<strong>與<b> 。或者使用基於<table>與<div>的表格。這些是與語法相關的決定，每個人都有自己獨特的寫作風格。

內容作者真正應該關注的是內容和語義，而不是設計。

有很多帶有純文本格式語法的標記語言，儘管 Markdown 是自然的選擇，因為它被 GitHub、Atlassian 和 WordPress 本身等巨頭廣泛使用。

選擇和安裝 Markdown WordPress 插件

WordPress.org 存儲庫中只有兩個 Markdown 插件有超過 1,000 次活動安裝。 WP-Markdown 和 JP Markdown。是的，Jetpack 也有一個 Markdown 模塊，但是只為一個模塊安裝這個“怪物”是沒有意義的。最初，我安裝了 WP-Markdown，因為根據屏幕截圖，它可以輕鬆選擇哪些帖子類型將支持 Markdown。不幸的是，該插件不起作用（上次更新是在 3 年前）所以我們最終沒有使用它。然後，我安裝了 JP Markdown。該插件確實有效，但有一些我不喜歡的東西：

降價在所有帖子和頁面上自動激活。
markdown 語法沒有被保留，它被自動轉換為樣式化的 HTML：

這很糟糕，因為數據作為豐富的 HTML 而不是 markdown 存儲到數據庫中（我驗證了這一點）。此外，它不會對富 HTML 編輯添加任何限制。因此，如果將來我們想遷移到另一個系統，則無法導出降價。

然後我找到了使用 Jetpack 的 Markdown 模塊的 WP Markdown Editor，這就是我們最終使用的那個。即使我們仍然需要進行一些自定義：

該插件會在激活後禁用所有帖子和頁面的豐富編輯。我們想擺脫僅在我們的文檔頁面上進行的豐富編輯。
該插件使用自己的降價編輯器覆蓋所有帖子和頁面的現有編輯器。同樣，我們希望僅在我們的文檔頁面上擁有它。

您可以在此處查看這些更改：
https://github.com/Freemius/wp-markdown-editor/commit/706bce0c23943c82d102c67a09e18dac32c66207

你可以從這裡下載分叉的版本（只有一些微小的變化）：
https://github.com/Freemius/wp-markdown-editor

然後，我們添加了一個簡短的函數，註冊docs CPT 以支持降價編輯，並取消註冊post和page類型以保留 HTML 富編輯器：

最後，我們不得不調整 WordPress 的默認導出功能，以便它會導出 markdown 代碼而不是 HTML 豐富的內容。我們通過掛鉤the_content_export過濾器來做到這一點：
太棒了——我們的 KB 由 markdown 提供支持，並且可以輕鬆導出。

添加 YouTube 和 Vimeo Markdown 支持

視頻是任何知識庫的重要組成部分。不幸的是，Markdown 不支持視頻。令人高興的是，WordPress 使添加短代碼和幾行代碼變得非常容易。我們豐富了 Markdown 語法以支持添加 YouTube 和 Vimeo 視頻：

作為獎勵，我們使視頻大小響應和移動友好，視頻添加現在使用視頻 ID 變得直觀和直接：
[youtube gj6aoYG4fUI]
[vimeo 185625717]

添加漂亮的標註簡碼支持

默認的 Markdown 語法確實支持塊引號，但它沒有為不同的標註提供語義，如提示和警告，這些不是強制性的，但對於良好的知識庫很重要。

WordPress簡碼再次拯救

這是它在前端的外觀：

我們添加了fs_前綴，以防止與我們將來可能安裝的插件發生任何潛在衝突。

為 Pretty Code 添加 SyntaxHighlighter

WordPress 和 WP Markdown 編輯器都沒有代碼語法高亮。由於 Freemius 是一個面向開發人員的平台，而且我們的文檔附帶代碼示例，因此添加語法突出顯示至關重要。我們選擇使用 SyntaxHighlighter Evolved，因為它由 Automattic 提供支持，就像 WP Markdown Editor 插件使用的 Jetpack 的核心 Markdown 模塊一樣。查看 Markdown 渲染代碼可以發現它們實際上是集成在一起的：

$this->use_code_shortcode = class_exists( 'SyntaxHighlighter' );

驚人的！正確的？不幸的是，似乎沒有什麼是開箱即用的完美，並且代碼呈現不正確。它通過將特殊字符轉義到相應的 HTML 實體來搞亂 Markdown 多行代碼部分。它不僅“破壞”了前端渲染的代碼，而且還在數據庫中存儲了 Markdown 代碼部分的轉義 HTML 版本。這不利於內容保存和潛在的數據導出。因此，我們別無選擇，只能對插件的代碼進行一些調整。您可以在此處查看確切的更改：
https://github.com/Freemius/wp-markdown-editor/commit/672695be8b29c57f7fa7ca580d29368b9e57af68

現在我們有了一個漂亮的、移動友好的、基於 Markdown 的知識庫，具有視頻支持、標註和代碼語法突出顯示。是的！

我們仍然需要讓它快速和安全（幾乎就在那裡！）。

我們如何使我們的 WordPress 知識庫變得超快？

我們選擇 WP Super Cache 是因為它廣受歡迎（超過 100 萬次活動安裝），由 Automattic 開發和維護，免費且相對容易設置。

添加磁盤權限

創建可寫緩存文件夾： mkdir /path/to/your/wordpress/wp-content/cache/ setfacl -Rm user:apache:rwx /path/to/your/wordpress/wp-content/cache如果權限行沒有工作，使用以下內容： chmod 777 /path/to/your/wordpress/wp-content/cache/

啟用緩存

通過將以下內容添加到wp-config.php文件來啟用緩存：

/** Enable Caching */
define('WP_CACHE', true);
define( 'WPCACHEHOME', '/path/to/your/wordpress/wp-content/plugins/wp-super-cache/' );

現在我們只需要打開緩存，您可以通過 WP Admin → Settings → WP Super Cache 來實現：不要忘記單擊“更新狀態”按鈕進行保存。您可以通過以隱身模式打開 WordPress 站點上的任何前端頁面並檢查源代碼來驗證緩存是否正常工作。當 WP Super Cache 工作時，您應該在頁面源代碼的底部看到以下 HTML 註釋：

<!-- Dynamic page generated in 0.848 seconds. -->
<!-- Cached page generated by WP-Super-Cache on 2016-10-13 21:35:40 -->

<!-- super cache -->

這已經比在沒有任何緩存的情況下提供頁面要好得多。但是，這仍然會觸發整個 PHP、WordPress 和 MySql 堆棧。如果我們想讓我們的網站快如閃電，我們需要添加服務器級緩存。

配置服務器級緩存

如果您像我們一樣使用 Nginx，以下是我們使用的配置： WP Super Cache Nginx 配置規則提示： Nginx 配置規則包括一堆if規則。 為了節省您寶貴的時間，請確保所有if規則都在location指令之外，否則，它將破壞整個處理過程（我浪費了幾個小時來解決這個問題）。如果您使用的是 Apache，您可以在 WordPress.org 的插件安裝說明頁面中找到 .htaccess mod_rewrite規則：https://wordpress.org/plugins/wp-super-cache/installation/ 最簡單的測試方法在不影響您的站點的情況下進行服務器級緩存是按照以下步驟操作：

創建並發布一個虛擬帖子，設置以下 slug `dummy-cache-test`。
以隱身瀏覽器模式加載頁面，確保它已緩存。

將以下代碼添加到wp-config.php文件的頂部：

if ( false !== strpos($_SERVER[REQUEST_URI], 'dummy-cache-test') {
    echo 'Server caching is off';
    exit;
}

添加代碼後，以相同的隱身瀏覽器模式重新加載頁面。如果頁面加載正確——服務器級緩存打開如果您收到消息“服務器緩存已關閉”，則說明有問題。

不要忘記從wp-config.php文件中刪除該添加內容，並在完成後刪除虛擬帖子。 太棒了——我們已經設置了緩存，現在所有頁面都直接從靜態緩存的 HTML 文件中提供，跳過 PHP 和 WordPress。

添加 CDN

儘管 KB 已經處於相當良好的狀態，但來自新瀏覽器的每個頁面視圖都會“命中”我們的服務器。因此，我想通過增加一層來消除這種情況——CDN。

CDN 的明顯優勢是全球數據中心分佈、高可用性以及服務器資源的大量減少，尤其是在靜態情況下。頁面將直接從 CDN 加載，甚至無需“接觸”我們的服務器。

我對 CloudFlare 評價不夠高。多年來，我們一直在使用他們的 CDN（以及他們額外的好東西），而這一切的瘋狂之處在於——您可以免費使用它！沒錯——他們 95% 的功能完全免費。

舉個例子，假設您在網站上有一個受歡迎的靜態頁面，每天獲得 500 萬次獨立訪問。忽略代理服務器和 ISP 緩存，這將觸發您的服務器每天至少 500 萬次點擊。當您使用像 CloudFlare 這樣的 CDN 時，這個靜態頁面每天只會從您的站點加載幾次（基於 CDN 緩存清除頻率）。

以下是我們擁有的僅提供圖像的子域的一些真實統計數據：

看看這些數字——我們為我們的服務器節省了超過 600 GB 的帶寬。如果您設置了 WordPress + WP Super Cache Plugin + Server Level Caching + CloudFlare CDN，您可能可以使用 5 美元/月的 DigitalOcean 液滴，而不會出現任何縮放問題！

讓我們一起做一些數學運算……WordPress 是免費的，WP Super Cache 是免費的，CloudFlare CDN 是免費的……哦——可擴展的 WordPress 只需 5 美元/月。 瘋了吧？！

我們如何自定義 KB 搜索來服務緩存數據？

默認情況下，WordPress 搜索永久鏈接結構使用查詢字符串s=參數來傳遞搜索查詢。有一個很好的理由，WP Super Cache 會忽略查詢字符串。因此，我們必須對搜索 URL 結構進行一些小調整以使其正常工作：

此更新將 URL 結構更改為由 WP Super Cache 緩存的freemius.com/help/documentation/search/{query}/ 。

繁榮！甚至我們的搜索結果現在也被緩存了。

我們如何保護我們的 WordPress 知識庫？

安全是關鍵。任何公司，尤其是初創公司，最不想處理的就是安全漏洞。它可能會損害您的聲譽，冒著您的 IP（知識產權）風險，並花費數小時甚至數天的時間來恢復控制權和數據。

許多開發人員喜歡談論 WordPress 並說它不安全。根據數字——是的，他們可能是對的。由於 WordPress 是最流行的網絡平台，它也是黑客的第一目標，而且這些數字是有道理的——Duh……

他們不明白的是，WordPress 作為一個平台可能是最安全的項目之一。漏洞主要來自舊的、過時的 WordPress 版本、第三方插件和主題，以及設置弱密碼的用戶。

所以我們要做的第一件事是在我們的源代碼中消除任何關於 WordPress 的概念，以減少受到攻擊的機會。

1. WordPress adds a bunch of (mostly) unuseful metadata to the head of every page which is pretty much unique to WordPress, let's get rid of that by adding the following code to the theme's functions.php file:

2. Many WordPress plugins add HTML comments with a unique thumbprint that are easily identified. For example, Yoast SEO adds the following code:

<!-- This site is optimized with the Yoast SEO plugin v3.7.0 - https://yoast.com/wordpress/plugins/seo/ -->

That makes it easy for attackers to identify the site as WordPress.

Remember CloudFlare?

It has a checkbox to automatically minify HTML and get rid of all the HTML comments added by different plugins, themes and WordPress core:

完畢！

3. Another known identifier of WordPress is the /wp-admin/ path to the login page. We installed WPS Hide Login, and configured our own “secret” path to the login page.

Assuming you set your login to your-site.com/my-secret-login/ make sure you add that path to WP Super Cache exclusion list. You can find it under WP Admin → Settings → WP Super Cache → Advanced:

Otherwise, it might mess up things when using SSL.

4. No need to mention – you and your team should be keeping your passwords strong! You can use a plugin like Force Strong Password to enforce a 'strong passwords' policy.

5. Force your login and WP Admin browsing via HTTPS to prevent password sniffing. You can achieve that by adding the following defines to the wp-config.php file:

define('FORCE_SSL_ADMIN', true);
define('FORCE_SSL_LOGIN', true);

6. One of the most popular attacks on WordPress sites is Brute force attack. Having a strong password policy helps, but can't really protect against it. Thus, we installed Google Captcha plugin that adds a simple captcha validating it's a human being:

Also, we installed Login Watchdog, a lightweight plugin that automatically bans suspicious IPs after pre configured amount of failed logins.

And if you are using CloudFlare as I recommended, it comes with a security layer against any threats, and since it's widely used, it has a “network knowledge” to protect your site from IPs that were attacking other sites powered by CloudFlare.

7. You should also secure WordPress on the server layer, preventing direct access to files like wp-login.php , hiding sensitive files, etc. Just follow this post:
https://lamosty.com/2015/04/14/securing-your-wordpress-site-running-on-nginx/

So yes – as long as there is a login page to our WordPress, it would never be secure as a pure static website. But the fact that we have turned our KB's frontend to static, hidden any evidence that we are using WordPress, added brute force protection and forced the login via HTTPS with a strong password policy, makes it very very (very) hard to hack.

I would dare to say that the only way the Knowledge Base will be hacked is if a security dojo will target our site specifically (that's rare, and I'm NOT calling anyone for a challenge).

輪到你了

Hopefully, this (very) elaborate article/tutorial will be useful for you when you come to make the important decision of what to go with for your knowledge base documentation solution.
No doubt, there's a lot to take into account here, and many of the decisions we made were influenced by our very specific needs & desires.

You could either copy & paste the entire process and customizations, or go deeper and customize it according to your specific needs. What's more important is to grasp the line of thought that lead the decision making and choosing & picking what's right for us. It was not easy because as I've shown – there are quite a few viable options out there, however, it did pay off, as Freemius now has an awesome Knowledge Base center, which is super customizable, lightning fast and scalable!

Hope you have a clear view how you can get started implementing and setting up your own documentation solution.

祝你好運！