站診斷分析的基本思路

引語:建議兩三行左右

一．網站基礎數據分析 （整個方案中，基礎分析沒有那么重要，不要占用過多比例）

注：必須找出競爭對手進行比較（一般三到五個）如果被同一競爭對手壟斷了只需要分析當前競爭對手就可以了（前提差距不大情況下）實力相當很重要（比自己高點可以觸手可及的）！

舉例分析：

根據上表可知：

1、在權重方面，百姓網與58，趕集相比有一定差距（先擺事實）權重在很大程度上影響網站的綜合表現。如：排名，收錄等。

2、在收錄方面，百姓網與趕集相比存在一定差距，但與58相比存在較大差距。而收錄量在一定程度上，影響站點的搜索表現

綜上所述，百姓網在權重和收錄方面與競爭對手（如果明確可以直接說）相比存在差距，因此需有針對性提升加大投入。詳細情況，下面進一步分析。

二、關鍵詞分析

1、首頁

1）首頁定位分析（網站屬于品牌展示型的就不需要布局關鍵詞了）（只限于首頁、例如：新浪）

2) 關鍵詞研究分析（關鍵詞挖掘、關鍵詞分析）（最好有截圖說明白）

3) 針對該網站首頁標題布局分析

4）提出布局建議（如果是求職，可以適當寫一下就可以了，甚至不寫）

2、欄目頁

1）分析關鍵詞布局是否得當

2）提出解決建議

3、篩選頁

1）分析關鍵詞布局是否得當

2）補充：關注調用規則是否得當（缺失、重復）

4、詳情頁

1）標題是否包含關鍵詞

2）標題是否具有吸引力

三、URL分析

1、首頁

常見問題：URL不唯一。如：a.com 、 www.a.com 、 www.a.com/index.html

分析：URL不唯一，分散權重，不利于權重集中

2、欄目頁/篩選頁

1）URL大小字母混合，如：www.a.com/Gjgwy/Bj-201.html

2）URL層級過深，出現不必要的層次

3）動態URL

注：對于 1)，2）兩種情況，如果是成熟網站，可暫不修改（如果修改對整個網站影響太大了）

對于 2）的情況如果是新站，可以直接去掉（規則中的字段刪除），如果是成熟網站，可新增一套URL規則

3、詳情頁

1、URL層級過深

2、動態URL

四、站內優化分析

1、首頁

1）首屏布局分析（將重點內容優先展現）

2）首頁相關性布局分析

3）用戶體驗分析（功能、交互）-----可做可不做

2、欄目頁/篩選頁

1）相關性布局分析（頁面主體版塊是否適當布局關鍵詞）

2）是否適當有相關鏈接推薦（構建站內鏈接結構）

3、詳情頁

1）相關性布局分析（正文中是否適當布局關鍵詞）

2）文章正文是否適當布局錨文本鏈接（一般是用目標關鍵詞）

3）正文中是否具有引導性連接推薦(購買營銷)----不做強制性要求

4）正文其他版塊是否有相關鏈接推薦

五、站外優化分析

1、外鏈質量

1）錨文本是否是用目標關鍵詞

2）外鏈平臺是否相關

3）外鏈平臺權重是否高

2、新媒體平臺運營狀況（微博、微信等粉絲量、互動量）----不強制性要求

六、重要標簽的使用

H1標簽：用于標題

Alt：用于圖片

Nofollow：告訴蜘蛛不要傳遞權重，不繼承權重之類的

七、其他

1、JS（文字、URL、不能放置JS中）、主要是看重要的內容能不能在源代碼中看不看的到，

2、404

3、網站地圖（html、xml）

注：html版本的網站地圖，用戶可正常瀏覽，搜索引行可識別

Xml僅供搜索引擎查看（小爬蟲）

八：總結

第一句話：表達該站存在的2-3個主要問題（簡明扼要說明即可）

第二句話：表達該站仍存在較大優化提升空間

第三句話：表達自己加入該公司的意愿

總結就是一段話，一般都是三四行就可以了

多深度文章，請關注云計算頻道：https://yq.aliyun.com/cloud

視覺中國集團（Visual China Group）創立于2000年6月，是中國領先的視覺影像產品和服務提供商。視覺中國集團是以“視覺創造價值，視覺服務中國”為愿景的A股唯一互聯網文化創意上市公司（股票代號000681，股票簡稱：視覺中國）。視覺中國集團以“視覺內容與服務”、“視覺社區”和“視覺數字娛樂”三大業務板塊為核心，擁有中國最大的視覺內容互聯網版權交易平臺，同時為國內的主題公園、城市綜合體提供領先的數字娛樂整體解決方案。旗下包括華蓋創意(Getty Images China)、漢華易美(China Foto Press)、東星娛樂（TungStar）、視覺ME社區（shijueme）、艾特凡斯（Advance）等業界著名品牌。集團擁有近萬名簽約攝影師和藝術家，并同海內外數百家圖片社、影視機構、版權機構廣泛合作，為媒體、企業主、廣告公司等各類客戶提供專業的圖片、影視、音樂、特約拍攝、創意眾包、視覺化營銷等一站式服務。

選擇云平臺

視覺中國集團目前有分布在北京市各區的5個機房，我們的應用分布在這五個機房，數據間調用復雜且低效，運維維護成本高，每年的預算更是給企業帶來一定的負擔。為了擺脫這種模式我們決定云化，考察了騰訊云，華為云，ucloud等廠商，最后選擇了更能切實解決我們問題且更值得信賴的阿里云平臺。

我們采用了基于阿里容器云的同城雙活微服務架構（consul+template+registrator），這樣既能保證服務的高可用，也在CI,CD方面有所作為。使用到的產品有ECS,RDS,OSS,REDIS,消息通知服務，DATAV，QUICKBI，切圖服務，RAM，容器云，云盾，SLB等十幾種。

遷移上云

我們首先進行線下實體機房的微服務的搭建及測試，確保服務可用后進行云化的考量。整個應用遷移過程分為幾個步驟：

• 阿里云資源申請。包括ecs，rds及oss等

• 容器云測試。簡單搭建幾個docker測試可用性

• 部署微服務。基于consul+template+registrator進行部署

• 代碼部署。把jar包等通過jkenins進行部署

• 功能測試。

• 性能測試。

• 灰度發布。A/B test

• 部分應用遷移。

• 觀察期

• 整體業務上線

• 觀察期

• 遷移完畢

整體交付完成之后，我們的CI、CD基本上做了實踐，研發發布代碼無需經過運維干涉，自動發布，自動部署一鍵完成。

云端架構解析

架構要點解讀：

1. 容器集群是Region級別的服務，集群內可以包含多個可用區的ECS。

2. 容器服務支持將同一個服務的容器調度在不同的可用區（zone）里，這是通過編排模板中的availability:az=xx標簽來實現，具體參考：https://help.aliyun.com/document_detail/26018.html?spm=5176.doc26086.6.149.VT2kDs

3. SLB本身具有跨機房高可用特性，使用主、備在不同可用區的SLB類型即可。

整體架構就是基于容器云的同城雙活架構，其實我們還有異地災備。

交付采取鏡像的交付方式，gitlab上傳代碼后通過jenkins進行打包操作，鏡像交付到開發環境，功能驗證沒問題后，gitlab合并代碼到test環境鏡像交付后進行test環境的功能及性能測試。

最后將鏡像推送至生產環境，生產環境采取雙consul多數據中心模式，可用區A連接位于A區的consul master，同時將注冊信息同步至位于可用區B的consul master，這樣保證多區的微服務集群高可用。

兩個區共用基礎資源，RDS通過DTS同步至測試環境，測試環境和dev環境共用一套RDS。我們的架構在滿足持續交付，持續部署的同時也滿足了高可用的需求，每個微服務都是集群，這樣基于容器層，ECS層，consul層，微服務層，任何節點出現問題對用戶都是不可見的，實現了高可用。

上云前后分析對比

1. 成本上可以做到有效的控制，隨時做到服務的升降級。

2. 阿里云幫助我們實現了故障主機的實時遷移，保障了業務的可用性，運維也比較省心。

3. 在安全方面基于云盾和先知等產品的安全防護可以做到多層次的保障，極大提高了我們的服務安全性。

4. 監控方面也很細致和全面，支持自定云完全滿足我們的需求。成本方面可以隨時關注費用中心，自行進行分析。

5. 效率方面，因為是基于容器云的微服務架構，這方面也有非常大的改善。

以上幾點任何一點在傳統機房的模式下想做到全面和高效都是比較困難的，這也是我們為何進行云化的原因。

上云遇到的問題及解決方法

遇到的問題還是比較多的，我列舉幾個典型的問題。

1. 中美oss同步大文件有數據重傳問題及日常傳輸方案。穩定性建議采取高速通道，日常傳輸采用multipart分塊實現

2. 云端支持批量上傳數據的壓縮及打包下載解壓縮功能。通過udf實現

3. oss子賬戶授權后只能看到自己目錄內容。通過ossfs實現

4. 跨境oss數據接收后無法確實該刪除的文件。通過跨境消息通知機制實現

5. 跟進不同的圖片主題進行切圖參數的相關匹配。通過智能識圖完成

6. 數據大屏展示。通過datav和quickbi實現

7. ddos攻擊防護。通過高防ip及waf防火墻實現

8. 容器云日志采集和查看。通過sls實現