一些SEO進行網(wǎng)站開發(fā)/數(shù)據(jù)分析的利器

時間：2023-05-26 01:48:02 | 來源：網(wǎng)站運營

時間：2023-05-26 01:48:02 來源：網(wǎng)站運營

一些SEO進行網(wǎng)站開發(fā)/數(shù)據(jù)分析的利器：我的開發(fā)經(jīng)驗是從初中開始的，用文曲星里面的GVBASIC編寫一些MOD游戲；高中印象比較深的，是用VB給小說寫了一個分割程序——iPod備忘錄可以用來看小說，但每個文件只支持幾百幾千字，很有限，于是要把大文件分割成諸多小文件。

大一時候，成為了學校上萬個新生里面的幾十個計算機基礎(chǔ)免修的之一。我們幾十個人的課改為了C語言，在學了點最皮毛的C語言之后差點沒被它勸退。

于是其實學生時期也沒學到什么管用的開發(fā)技能。但至少有一個好處是，當我做SEO之后，立馬就意識到了開發(fā)網(wǎng)站、分析數(shù)據(jù)是需要借助技術(shù)手段的，立馬去學了PHP，后來發(fā)現(xiàn)Python更好用，于是從2011年開始寫Python至今。

在之前有幾年的時間里面，我會著力推崇技術(shù)優(yōu)先。乃至于在面試他人的時候，我會考驗別人寫正則表達式的能力。

至今，我仍然非常明確的認為，盡管懂正則表達式遠遠不意味著能做好SEO，但反過來，完全不會正則表達式的人，也是不可能擁有優(yōu)秀的SEO能力的。因為SEO的核心重點之一是研究排名，而研究排名是需要分析數(shù)據(jù)的，分析數(shù)據(jù)又是離不開正則表達式的。

xxx.com/zufang/123.htmlxxx.com/zhaopin/456.htmlxxx.com/zufang/beijing/xxx.com/zufang/list.html如何便捷且精確的把前兩個URL歸為一類去進行分析，就是個典型的正則表達式問題。但我現(xiàn)在通常不會多加強調(diào)技術(shù)這回事了。技術(shù)能力對于SEO是必備的，但也只是必備的而已。

這些年我逐漸意識到，SEO是一種最典型的研究性領(lǐng)域，和物理學等領(lǐng)域的研究在本質(zhì)上可能并無差別。說到研究，那就是統(tǒng)計數(shù)據(jù)（或是收集非數(shù)據(jù)性的事實）->獲得猜想->驗證猜想。其中，一些數(shù)據(jù)或非數(shù)據(jù)的分析思路方向（乃至說是哲學）的重要性，無疑是遠高于獲取數(shù)據(jù)來分析這種技能本身的。

（但有個特殊的方面是，如果懂得些技術(shù)原理，可以更容易理解搜索引擎的運作機制。尤其若懂得機器學習、深度學習的底層原理，諸如深刻理解它們的結(jié)果，是基于訓練集的通過歸納法所得出的結(jié)論，會顯著利于理解一些由這些手段弄出來的，偶爾與常識相違背的排序因素）

但仍然，掌握些更適用的技術(shù)手段，有時可以給我們節(jié)省下極大量的時間。尤其當我們想自己做網(wǎng)站來獲取SEO流量的時候，那么自行從框架級別開發(fā)，無論是網(wǎng)站性能負載或是功能的可擴展性上面，都會遠遠優(yōu)于使用一些現(xiàn)成CMS。因此，本文介紹些我所采用的高效技術(shù)手段。

我認為把做SEO的30%時間放到寫代碼上去，會是一個比較合適的投入比例。

應(yīng)當明白的是，許多技術(shù)圈子更主流的解決方案，在代碼實現(xiàn)上非常之臃腫，這主要是基于大型項目的開發(fā)層面上，可維護性是非常重要的考量。如果自己寫出的代碼，換一個人很難接手去修改，乃至于自己隔了幾個月回來再看也覺得很陌生從而無從下手，那么，哪怕這套技術(shù)解決方案可以用十行代碼搞定別人幾百行代碼搞定的事情，它通常仍然不會成為最主流的技術(shù)解決方案。

但對于非專業(yè)技術(shù)人員而言是相反的，技術(shù)開發(fā)的簡單程度及開發(fā)效率往往非常關(guān)鍵。可維護性就相對次要許多了——如果不給網(wǎng)站亂加功能，那么大不了重構(gòu)一整個網(wǎng)站也很可能不過是幾天的事。

本文介紹的都是簡單高效的技術(shù)手段。

---

1. Python下載網(wǎng)頁 PycURL->Requests

我將PycURL替換為Requests是幾年前的事情了。因為Requests現(xiàn)在已經(jīng)是Python內(nèi)置庫，想來應(yīng)該大部分人都已經(jīng)用它了。但早在Requests還沒有流行之前，我自行包裝了PycURL來使用。盡管對于單獨下載一個網(wǎng)頁內(nèi)容這樣的簡單需求，使用起來是簡單了，但底層代碼實在談不上簡潔優(yōu)雅：

import pycurl, StringIOdef curl(url): s = StringIO.StringIO() c = pycurl.Curl() c.setopt(pycurl.URL, url) c.setopt(pycurl.REFERER, url) c.setopt(pycurl.FOLLOWLOCATION, True) c.setopt(pycurl.TIMEOUT, 60) c.setopt(pycurl.ENCODING, 'gzip') c.setopt(pycurl.USERAGENT, 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36') c.setopt(pycurl.NOSIGNAL, True) c.setopt(pycurl.WRITEFUNCTION, s.write) for k, v in kwargs.iteritems(): c.setopt(vars(pycurl)[k], v) c.perform() c.close() return s.getvalue()html = curl(url)而Requests庫，口號是「HTTP for Humans」，下載一個網(wǎng)頁只需要一行：

import requestshtml = requests.get(url).text這樣的語法，無疑是更適合非專業(yè)開發(fā)人員的。大多數(shù)情況下，我們并不想涉及到底層實現(xiàn)里面去，而是單純想要只用一句代碼就解決一個問題。Requests正是較為完美的實現(xiàn)了這一點。

下面將推薦的一些，都有著類似于PycURL遷移到Requests這樣的巨大的便捷性提升。

2. 全文檢索 ElasticSearch->MeiliSearch

全文檢索在SEO的主要運用場景，是做聚合頁和做相關(guān)文章匹配。

ElasticSearch之所以快速占據(jù)了全文檢索的大半江山，一方面肯定是性能，另一方面想來也有代碼實現(xiàn)簡潔的功勞。畢竟它對比起上一代的Sphinx等全文檢索，已經(jīng)省事了太多了。

尤其在使用了ElasticSearch-DSL以后，一些基礎(chǔ)索引+查詢需求的代碼量可以從幾十行縮短到十行左右，一度被我認為已經(jīng)接近是最理想選擇了。

直到發(fā)現(xiàn)了MeiliSearch，對比之下頓時認為ElasticSearch是多么臃腫到可怕的程度。或許不能算是ElasticSearch的問題，只是MeiliSearch在代碼簡潔性上面實在太極致了。

Meili看上去像是個國產(chǎn)粗制劣造全文索引的隨意名字，但實際上它是個國外開發(fā)的，基礎(chǔ)功能健全且非常高效的全文檢索。除非有些高級的功能需求，或是數(shù)據(jù)體量極大乃至需要集群，否則至少我目前看來它基本上足夠替代ElasticSearch。

import meilisearchidx = meilisearch.Client('http://127.0.0.1:7700').index('test')# 索引idx.add_documents(docs) # docs是包含一個或多個dict的list# 查詢for hit in idx.search(query)['hits']: print(hit)在基礎(chǔ)搜索需求下，沒有任何一行多余的代碼。

如果對全文檢索的原理有所了解，那么應(yīng)該知道，因為倒排索引要反過來匹配正排索引，所以每個文檔必須有一個唯一ID。

對于MeiliSearch，當首個插入文檔里面有一個key包含「id」的時候，無論它是「id」、「uid」還是「_id」等，都會自動被設(shè)置為唯一ID（當然也可以自行設(shè)置）。因為大部分情況下，數(shù)據(jù)庫里面讀出來的數(shù)據(jù)都是會有一個唯一字段是命名包含ID的，所以這樣的自動ID規(guī)則使得大部分情況下，數(shù)據(jù)庫讀出來的數(shù)據(jù)可以不經(jīng)任何修改與配置，直接存到全文索引里面。

除了代碼層面以外，環(huán)境配置上，MeiliSearch也比ElasticSearch省事得多。單文件即可運行，自身支持中文分詞（jieba實現(xiàn)）無需安裝插件之類的，部署起來兩分鐘的事。

3. 瀏覽器自動化 Selenium->Playwright

瀏覽器自動化在SEO的主要應(yīng)用場景，是在一些防采集比較嚴的網(wǎng)站，或是在一些JavaScript使用較多的網(wǎng)站，去做數(shù)據(jù)抓取。比如Google的SERP或是百度鳳巢的搜索詞數(shù)據(jù)。

當然它也是快排基礎(chǔ)。只不過懂得用瀏覽器自動化手段，和做出快排效果那還差了十萬八千里。

Selenium大概是我之前幾年之中日常會用的里面，語法最讓人難受的了，以點擊一個頁面元素為例：

driver.find_element_by_css_selector('div#content').click()來看一下微軟最近剛開源的Playwright：

page.click('div#content')默認直接采用最常用的CSS選擇器。那比如要用xpath選擇器該怎么辦呢？

page.click('//html/body')若是//開頭就轉(zhuǎn)為使用xpath選擇器，多么簡潔。

不僅是語法，其余許多方面它也對比起Selenium有巨大的優(yōu)勢。而且還有個很好用的操作錄制功能，可以省下大部分的開發(fā)時間。

4. 前端CSS框架 Bootstrap->Tailwind

在Bootstrap4版本出了以后，我已經(jīng)感覺它很好用了，一些實用類足以解決大部分樣式問題，乃至于我越來越少的用到它自己提供的組件樣式。

Bootstrap5提供了更多的實用類，開始顯得更好用了。但它考慮到有少數(shù)國家語言的閱讀習慣是從右到左，因此pl(padding left)之類的都改成了ps(padding start)，讓我這樣不需要去做多語言網(wǎng)站的人，覺得特別的別扭。

這就愈發(fā)提供了理由去轉(zhuǎn)為一個更專注于實用類的CSS框架，諸如Tailwind。

<div class="rounded border shadow p-4 hover:bg-gray-600"> content</div>Bootstrap里面有提供少量預置的背景漸變，而Tailwind里面的背景漸變能指定漸變方向，以及起始、終止顏色；

Tailwind的實用類對于字體大小，內(nèi)間距、外間距都大量梯度可選擇。除非對于大小、間距有著特別的苛求，否則都可以只通過添加class搞定；

Tailwind還支持把hover等選擇器也都用class搞定，這也是讓我覺得非常驚艷的一個地方。

我用它嘗試重構(gòu)了我的一個網(wǎng)站的CSS。原本在使用了Bootstrap實用類的情況下還寫了一百多行CSS，用了它就只剩下幾行了（因為有個需要使用nth-child選擇器的地方它不支持）。

5. 網(wǎng)站架構(gòu)

其它的一些主要技術(shù)解決手段，我在這幾年里面沒有更換過，簡述一下：

網(wǎng)站架構(gòu)：Linux + Nginx + Python(Flask) + NoSQL(MongoDB)

絕大部分CMS背后，都是PHP+MySQL的解決方案，乃至其中大部分CMS還是生成靜態(tài)頁面（默認不生成靜態(tài)的WordPress只要幾萬文章就撐不太住了），這是非常不科學的。

若十年使用PHP+MySQL的解決方案，那是因為它比起ASP等還是具有一定優(yōu)勢的，相對容易開發(fā)，此外沒什么其它更多選擇。但尤其2014年之后Python和NoSQL都火了起來，在一些簡單場景下，它們早就是性能與開發(fā)效率層面上都好上十倍百倍的選擇了。

（我是2011年就從PHP轉(zhuǎn)為寫Python的，當時Python和Ruby孰優(yōu)孰劣都還沒有絕對定論，但哪怕在當時，明眼人看起來結(jié)論應(yīng)該都是毋庸置疑的）

當然時至如今，MySQL之類的關(guān)系型數(shù)據(jù)庫，在大部分業(yè)務(wù)場景下是比NoSQL更好的選擇，但我們討論的是CMS等基礎(chǔ)建站場景。CMS是內(nèi)容管理系統(tǒng)，核心該做的事情無非就是把數(shù)據(jù)庫里面有的內(nèi)容展現(xiàn)給用戶。這正是NoSQL及其設(shè)計準則最擅長的場景。

至于數(shù)據(jù)與數(shù)據(jù)之間有什么內(nèi)在關(guān)系，不是CMS應(yīng)該去多加關(guān)心的，也因此沒有用關(guān)系型數(shù)據(jù)庫的必要性。

---

以上說的這些，對于沒有從Python框架用NoSQL寫過網(wǎng)站的人，可能比較抽象，不太容易具體的理解。所以我說些相對具體的可參考數(shù)字。

我之前開發(fā)過一個網(wǎng)站。有幾千萬的頁面、幾百萬的日均PV（其中有近30萬UV是用戶流量，其余是爬蟲抓取量），每個頁面都有全文檢索匹配/隨機匹配等規(guī)則的區(qū)塊展示。在這訪問規(guī)模下：

絕大部分國產(chǎn)CMS若不做靜態(tài)化頁面都是撐不住的。盡管如果用月均幾千元配置的服務(wù)器，做了靜態(tài)頁面多半還撐得住，但每次更新幾千萬的頁面會是個耗時極久的事情。為了在更新頁面的時期網(wǎng)站訪問不會崩潰，可能還要搞至少兩臺服務(wù)器做MySQL的讀寫分離。通常Memcached、Redis之類的緩存都得用上。

而我實際用的就是一臺4核8G的阿里云ECS，每月幾百元（但額外帶寬費用相對還要貴不少，沒辦法），且絕大部分時間CPU及內(nèi)存的冗余都極多，正常運行期間CPU占用到不了10%，于是極限情況下1核2G也應(yīng)該是夠的。

一開始我還做了在代碼層面做了頁面級的LRU緩存和區(qū)塊數(shù)據(jù)的TTL緩存，這本身是對應(yīng)場景下理論幾乎最優(yōu)的緩存策略，但后來才發(fā)現(xiàn)其實基本沒必要。只要數(shù)據(jù)邏輯沒往復雜了寫，服務(wù)器性能怎么都夠用。

畢竟偌大一個網(wǎng)站的后端總共就百來行代碼，能慢到哪兒去呢。反觀CMS，一個頁面的生成背后，動輒幾千幾萬行代碼。最終產(chǎn)出的一個頁面上顯示出來的就那么多東西，用手指往往都數(shù)得過來，每個小小東西后面平均對應(yīng)幾百行以上的代碼，想想那種代碼可能合理嗎？

我們應(yīng)當去盡量遵循一個對于業(yè)余開發(fā)人員比較適用的開發(fā)準則：

做一件事盡可能只用一行代碼。

（比如做一個相關(guān)文章區(qū)塊的內(nèi)容匹配，需要一行代碼還是幾十行代碼？）

如果幾行代碼里面還搞不定，那么不應(yīng)當去設(shè)法寫更多代碼，而該是轉(zhuǎn)為去找尋更簡潔易用的解決方案。

下面的代碼是我的一個電影站，其背后的核心代碼部分：

from flask import Flask, render_template, request, abortimport pymongo, meilisearchdb = pymongo.MongoClient().videoidx = meilisearch.Client('http://127.0.0.1:7700').index('video')idx.add_documents([ doc for doc in db.video.find() ])app = Flask(__name__)@app.route('/video/<int:_id>/')def video(_id): doc = db.video.find_one({'_id': _id}) if doc.get('delete'): abort(404) return render_template('video.html', random_video = db.video.aggregate([{'$match': {'category': doc['category']}}, {'$sample': {'size': 12}}]), **doc )@app.route('/video/<int:_id>/<source>-<int:play_id>.html')def play(_id, source, play_id): doc = db.video.find_one({'_id': _id}) if doc.get('delete'): abort(404) play_list = doc['source']['online'][source][play_id-1] return render_template('play.html', play_url = play_list['url'], play_label = play_list['label'], **doc )@app.route('/search/')def search(): query = request.args.get('query') return render_template('search.html', results = idx.search(query)['hits'], query = query )@app.route('/example-admin-path/')def admin(): info = '' if request.args.get('action')=='delete': if request.args.get('password')=='ExamplePassword': _id = int(request.args.get('_id')) db.video.update_one({'_id': _id}, {'$set': {'delete': True}}) info = '<a href="/video/%d/">頁面已刪除</a>' else: info = '操作密碼錯誤' return render_template('admin.html', info=info)在這幾十行的后端代碼里面，除了視頻簡介與播放頁面，還實現(xiàn)了搜索功能及支持屏蔽具體某個視頻的管理后臺?？窟@幾十行代碼做出來的頁面，和大部分電影網(wǎng)站CMS默認模板下的樣子已經(jīng)差不多了。

我貼出來的只是一部分，還有些非核心功能的被我刪減了。但實際線上的代碼，在加上首頁、欄目頁及其他諸多小功能之后，也不過只有一百來行的代碼。

尤其在搜索功能和管理后臺這塊的實現(xiàn)邏輯，讀者可以參考一下。因為通常情況下，大部分人做出來的類似功能，動輒幾十行以上的代碼。

像是一般來說后臺管理都是通過用戶名和密碼這樣的cookie來驗證用戶身份的，這樣的常規(guī)做法有許多好處，我們未來如果要進一步擴展功能，像是記錄某個視頻是誰刪的（對于一個公司里面可能有很多個員工有操作權(quán)限），那么這些常規(guī)做法自然是在功能上面更具有擴展性的；

但如果這個網(wǎng)站肯定只是我們自己維護，那么常規(guī)后臺實現(xiàn)方式就是極度臃腫的。我們只需要一個密碼框，來確保哪怕他人發(fā)現(xiàn)了這個頁面也無法惡意應(yīng)用，那往往就足夠了。

（如果對安全性有更高要求，那么就把GET改成POST，再結(jié)合上HTTPS，安全方面基本無憂）

可見，極簡的程序邏輯背后，首先是理清楚根本需求所在，剩下的事情往往就很簡單了。

這樣，整個網(wǎng)站的代碼、性能、可拓展性等方面就會有十倍百倍以上的提升。而基于網(wǎng)站可拓展性的提升，網(wǎng)站的SEO流量也就開始擁有了十倍百倍以上提升的機會。

6. 最后

技術(shù)畢竟不是我的專業(yè)領(lǐng)域，如果文中若有什么寫錯的毫不奇怪，歡迎指正。

另外，在我常用的技術(shù)解決方案里面，現(xiàn)在只有MongoDB相比起來是顯得額外臃腫的（但還是遠好于MySQL）。

在json儲存文檔的前提下，除了增刪改查只需實現(xiàn)通過索引的WHERE及SORT BY兩種查詢功能，這種情況下是否有什么解決方案，在Python環(huán)境擁有比MongoDB更簡單的語法及部署方式，但愿有人能幫忙告知。