Phỏng vấn Matt Cutts về SEO

Phong van Matt Cutts ve SEO

Nội dung buổi phỏng vấn với chuyên gia Matt Cutts? Matt Cutts là kỹ sư phần mềm của Google từ năm tháng 1/2000. Trước khi làm việc cho Google, ông đã hoàn thành đề tài nghiên cứu của mình về đồ họa máy tính tại trường Đại học North Carolina ở Chapel Hill. Ngoài ra ông cũng đã tốt nghiệp thạc sỹ tại trường UNC – Chapel Hill và cử nhân toán học và canh nghệ tại trường Đại học Kentucky.

Matt Cutts là tác giả của phần mềm Safe Search là bộ lọc hữu hiệu phục vụ cho Google. Ngoài kinh nghiệm làm việc ở Google, Matt còn nắm giữ những thanh tin tối mật khi làm việc cho Bộ Quốc Phòng Mỹ và anh cũng làm việc cho một công ty game. Anh chia se rằng Google là một trong những công việc thú vị nhất của anh cho tới nay. Hiện nay Matt đang quản lý đội Webspam cho Google. Matt nói về những vấn đề liên quan tới Webspam trên blog của mình.

Nội dung cuộc phỏng vấn như sau:

Câu hỏi: Chúng ta hãy cùng tìm hiểu khái niệm “crawl budget”. Theo tôi được biết thì Googlebot sẽ đi tới các website và tính toán số lượng trang nó sẽ phải Index trong một ngày và nó sẽ rời đi khi đã hoàn thành công việc.

Matt Cutts: Điều đầu tiên chúng ta nên nhớ rằng sẽ không có bất cứ một điều nào giống như “indexation cap”. Rất nhiều người nghĩ rằng một tên miền chỉ được Index một lượng trang nhất định. Nhưng googlebot không hoàn toàn làm việc như thế. “…Số lượng trang mà chúng tôi Crawl tương ứng với Pagerank của trang đó”
Cũng không có một giới hạn nào cho việc crawl. Cách tốt nhất để nắm được vấn đề này là chúng ta nên hiểu số lượng trang được Index tương ứng với Pagerank. Chính vì thế nếu bạn có nhiều liên kết tới trang chủ của bạn, chúng tôi sẽ crawl trang đó. Sau đó trang chủ của bạn có thể liên kết tới rất nhiều những trang khác và những trang đó sẽ có được Pagerank. Chúng tôi cũng sẽ crawl luôn những trang đó. Tuy nhiên, khi trang của bạn càng sâu thì đồng nghĩa với việc Pagerank của bạn sẽ có xu hướng giảm xuống.

Một cách lý giải khác là những trang có Pagerank thấp trong website của bạn sẽ phải cạnh tranh với rất nhiều những trang khác có cùng Pagerank hoặc có Pagerank cao hơn. Có rất nhiều trang trong website của bạn có Pagerank rất thấp hoặc bằng 0. Những trang có nhiều liên kết thường được nhận ra và crawl khá nhanh. Những trang có Pagerank thấp có xu hướng được crawl không thường xuyên.

Một điều cũng vô cùng thú vị khi nghiên cứu thuật ngữ “crawl budget” là mặc dù không có bất cứ một giới hạn nào trong crawl nhưng vẫn có khái niệm “host load”. Host load là số lượng kết nối đồng thời mà server có thể xử lý được. Tưởng tượng rằng website của bạn chỉ có thể xử lý 1 kết nối cùng 1 lúc. Điều này chỉ cho phép googlebot lấy 1 trang tại 1 thời điểm và dẫn tới việc “host load” sẽ rất thấp. Trong khi đó có một số trang như Facebook hoặc Twitter có thể có “host load” rất cao vì cùng một lúc các website này cho phép thực hiện nhiều kết nối.

Trang của bạn có thể ở trong một host ảo với rất nhiều website khác cùng một địa chỉ IP. Về mặt lý thuyết, website của bạn sẽ bị hạn chế về số lượng trang googlebot crawl. Nếu chúng ta chỉ có thể lấy ra 2 trang từ 1 website vào một thời điểm và chúng ta chỉ có thể crawl chúng vào một thời điểm cụ thể, sẽ đặt ra một câu hỏi liệu chúng ta có thể lấy được bao nhiêu trang từ host đó.

Câu hỏi: Chính vì vậy ở đây anh sẽ có hai nhân tố. Một là Pagerank, từ đây chúng ta có thể tính được số lượng trang có thể crawl được trên website. Nhưng “host load” cũng có thể ảnh hưởng tới kết quả của kết quả này.

Matt Cutts: Đúng như vậy. Cho tới nay, có một lượng lớn các website đứng ở vị trí hàng đầu mà Pagerank và những nhân tố khác có thể quyết định việc chúng ta sẽ đi sâu vào nghiên cứu website này như thế nào.Tuy nhiên “host load” cũng có thể có những ảnh hưởng nhất định với một website. Điều này dẫn tới vấn đề những nội dung trùng lặp. Tưởng tượng rằng chúng ta kiểm tra 3 trang từ 1 website và phát hiện ra rằng hai trang kia lại là bản sao của trang thứ 3. Chúng ta sẽ loại hai trang kia và chỉ giữ lại một trang. Đó là lý do tại sao nội dung của các trang có vẻ ít. Chính vì thế chúng ta có thể sẽ kiểm tra nhiều tới mức có thể từ 1 trang.

Nếu mà “host load” của bạn bị giới hạn, bạn chỉ có một lượng hữu hạn các trang đượng Crawl do giới hạn của webserver, khi bạn có những trang trùng lặp chúng tôi sẽ loại bỏ những trang đó điều này đồng nghĩa với việc bạn bỏ lỡ cơ hội có những trang có nội dung đặc biệt, chất lượng tốt được Index.

Câu hỏi: Chính vì chi phí cho những trang có nội dung giống nhau sẽ lãng phí “crawl budget”.

Matt Cutts: Đúng như vậy. Có một ý kiến cho rằng nếu nếu bạn có một lượng Pagerank cụ thể, chúng tôi sẽ kiểm tra nhiều website đó. Nhưng một số trang có thể bị loại và đó là một kiểu lãng phí. Điều này cũng có thể xảy ra ở host load khi chúng ta không thể truy cập rất nhiều trang.

Câu hỏi: Một khái niệm nữa mà chúng ta cần đề cập tới đó là khái niệm “link juice”. Tôi sẽ sử dụng thuật ngữ Pagerank nhưng tổng quát hơn sẽ được hiểu là “link juice”. Thuật ngữ “link juice” ở đây có thể được hiểu là có những mối liên hệ với những khái niệm như sự tin cậy và uy tín của thuật ngữ Pagerank. Khi bạn liên kết từ một trang tới trang bản sao, bạn đang lãng phí Pagerank của mình. Điều đó có đúng không?

Matt Cutts: Cũng có thể hiểu theo cách đó. Điển hình, nội dung trùng lặp không phải là một nhân tố quan trọng quyết định việc bao nhiêu trang sẽ được crawl, nhưng đó cũng là một nhân tố. Lời khuyên của tôi ở đây là nó sẽ trở nên hữu hiệu hơn nếu bạn có thể sắp xếp được cấu trúc của website. Vì sau đó bạn sẽ không phải lo lắng nhiều về vấn đề những trang có nội dung trùng lặp và những vấn đề khác đi kèm với chúng. Bạn có thể sử dụng  Redirects 301 cho những URLs trùng lặp sao để gộp chúng lại vào cùng một URL. Nếu bạn không thể dùng 301 Redirect, bạn có thể dùng thuộc tính canonical.

Một vài người không thể kết nối được với web server để thực hiện một 301. Nguyên nhân của việc này có thể là do họ đang truy cập vào mạng của trường học, free host hoặc là một host nào đó tương tự. Nhưng nếu họ có thể xử lý nó trong cấu trúc của website, thì sau này họ có thể giải quyết nó với 301 Redirect hoặc rel=canonical.

Câu hỏi: Đúng vậy, đó chắc chắn là một tiêu chuẩn vàng. Có thể hiểu là bạn có 1 trang và có 10 liên kết tới trang đó. Nếu 3 trong số những trang đó là những trang trùng lặp và bị loại bỏ thì bạn đã bỏ mất 3 cơ hội để được chúng tôi crawl.

(đối với những nội dung trùng lặp):” Chúng ta cố gắng gộp những trang đó lại hơn là loại chúng hoàn toàn”

Matt Cutts: Không cần thiết phải như vậy. Đó là một trường hợp mà chúng ta có thể thử nghiệm. Chúng ta cố gắng gộp những trang đó lại hơn là loại chúng hoàn toàn. Nếu bạn liên kết tới 3 trang có nội dung giống nhau, công cụ tìm kiếm sẽ có thể nhận ra đó là 3 trang giống nhau và chuyển link juice tới những trang đã được gộp lại này.

Đó không phải là trường hợp mà Pagerank bị lãng phí hoàn toàn. Nó phụ thuộc vào công cụ tìm kiếm và cách triển khai. Giả sử rằng các công cụ tìm kiếm đều triển khai khác nhau, nếu bạn có thể làm được việc đó trên website của bạn nơi mà các liên kết đều đi tới 1 trang duy nhất. Đó làm một điều thích hợp hơn.

Câu hỏi: Anh có thể nói them về Session IDs?

Matt Cutts: Đừng sử dụng nó. Ngày nay, hầu hết mọi người sẽ có một ý tưởng hay để tạo một website mà không sử dụng Session IDs. Về điểm này, hầu hết những người sáng tạo phần mềm đều nghĩ tới, không chỉ đứng ở góc độ công cụ tìm kiếm mà còn ở góc độ của người sử dụng. Người sử dụng thường có xu hướng click vào những link đẹp và họ cũng thường có xu hướng nhớ những liên kết trông đẹp mắt hơn. Tuy nhiên Nếu bạn không thể tránh khỏi điều đó, Google sẽ cung cấp cho bạn một công cụ để giải quyết vấn đề Session IDs. Người ta vẫn có thể làm như ở trong Yahoo!, nói một cách dễ hiểu là nếu một thông số URL không có giá trị hoặc không có thông số có thể sẽ bị bỏ qua, họ sẽ viết lại chúng với một URL đẹp hơn. Google cung cấp lựa chọn này cho người dùng và sẽ rất tốt nếu chúng ta sử dụng nó. Một vài công cụ tìm kiếm khác cũng làm như thế, nhưng sẽ tốt nhất nếu bạn không phải sử dụng Session IDs.

Câu hỏi: Cuối cùng, điều đó có thể dẫn tới tình trạng các nội dung trùng lặp

Matt Cutts: Đúng, chính xác là như vậy và công cụ tìm kiếm gần như có thể xử lý vấn đề này khá tốt. Những trường hợp điển hình nhất cũng không phải là vấn đề hóc búa nhưng tôi đã từng gặp một trường hợp mà ở đó rất nhiều trang với những phiên bản khác nhau được index với những Session IDs khác nhau. Với những website riêng của bạn thì bạn nên xem xét kỹ vấn đề này và bạn sẽ không phải lo ngại về việc công cụ tìm kiếm xử lý vấn đề này như thế nào.

Câu hỏi: Hãy thử xem xét những chương trình liên minh (Affiliate programs). Người khác gửi cho bạn những truy cập, họ đặt cho các URL đó một tham số. Bạn giữ những tham số đó trong suốt quá trình người khác vào thăm website, đó là một điều hoàn toàn bình thường. Liệu có phải công cụ tìm kiếm sử lý vấn đề này rất tốt hoặc là sẽ xảy ra nguy cơ có những nội dung trùng lập ở đây.

Matt Cutts: Nội dung trùng lập hoàn toàn có thể xảy ra. Nếu bạn tham gia các chương trình co-brand (Sử dụng chung một thương hiệu) mà sự khác nhau giữa các trang chỉ là biểu tượng và đó là cách mà những người sử dụng dùng chúng như những trang giống nhau. Công cụ tìm kiếm tỏ ra rất hữu hiệu trong việc cố gắng gộp những trang này vào với nhau, nhưng trong một vài trường hợp vẫn xảy ra tình trạng những nội dung trùng lặp.

Câu hỏi: Với những trường hợp như thế này vẫn có những giải pháp SEO kinh điển. Theo phương cách này, điều bạn thật sự cần làm là để họ đặt một tham số vào trong URL, nhưng khi người sử dụng click vào liên kết này để tới site của bạn, bạn sẽ 301 redirect họ về trang đó mà không cần tham số và để tham số đó trong cookie.

Matt Cutts: Cũng có thể làm như vậy. Điều này cũng giống như việc thuê trang để quảng cáo. Bạn có thể nghĩ tới việc tạo một trang con cho thuê quảng cáo trong một thư mục URL riêng biệt mà bạn có thể block vào robots.txt như một ví dụ. Quảng cáo hay những liên kết con chủ yếu là nhắm tới những người sử dụng thực sự chứ không phải là các công cụ tìm kiếm. Đó chính là điểm rất dễ nhận ra và bạn không phải lo lắng về việc những mã liên kết này sẽ bị rò rỉ hoặc tạo ra những nội dung trùng lặp nếu những trang này không được crawl ở phần đầu.

Câu hỏi: nếu Googlebot nhận ra một chương trình chương trình liên minh (Affiliate) liệu nó có đối xử với liên kết này như quảng cáo hay một Endorsement?
(với những link Affiliate) “..Chúng tôi sẽ không đếm chúng như Endorsement

Matt Cutts: Chúng tôi muốn xử lý những kiên kết này một cách thích hợp. Nhiều thời gian đồng nghĩa với việc những liên kết này về bản chất sẽ tiêu tốn rất nhiều tiền của. Chính vì vậy, chúng tôi sẽ không đếm chúng như một endorsement.

Câu hỏi: Hãy cùng tìm hiểu về faceted navigation. Ví dụ như, ở Zappos, người ta có thể mua giày theo số, theo cỡ, theo màu, theo nhãn hiệu và những mẫu giống nhau sẽ được thống kê theo 20 cách khác nhau. Điều đó như một bài toán đánh đố. Anh có suy nghĩ gì về trường hợp này?

Matt Cutts: Nói chung “Faceted navigation” có thể khiến nhiều người hiểu nhầm. Những người sử dụng thường không xử lý vấn đề này tốt, và trở nên mất phương hướng không biết mình đang ở điểm nào. Có thể có rât nhiều cách để lướt qua nội dung một trang. Nhưng nếu bạn muốn mỗi nội dung trang tương ứng với một URL thì cũng không phải là điều khó. Có rất nhiều cách để chia nhỏ và kiểm tra dữ liệu. Nếu bạn có thể tự quyết định cách nào là quan trọng và hữu hiệu nhất để có thể truy cập vào được nội dung thì bạn sẽ có cấu trúc riêng đối với các tham số URL.

Có thể lấy ví dụ như: Category có thể là tham số đầu tiên sau đó tới giá cả. Ngay cả khi một người đang xem qua giá cả và sau đó nhấn vào mục Catgory là điều hoàn toàn có thể làm được, chính vì thế hệ thống thứ bậc các điều bạn nghĩ sẽ được sắp xếp trong các tham số URL dưới dạng từng vị trí.

Theo cách này, loại quan trọng nhất sẽ được đặt lên đầu tiên và loại quan trọng tiếp theo sẽ được đặt ở vị trí thứ hai. Điều này có thể giúp các công cụ tìm kiếm phát hiện ra nội dung dễ dàng hơn chút ít bởi vì chúng có thể nhận ra rằng chúng có thể nhận được những nội dung hữu ích hoặc tương tự nếu chúng bỏ đi tham số cuối cùng này. Nói chung, “faceted navigation” là một vấn đề vô cùng hóc búa bởi vì bạn tạo ra rất nhiều cách khác nhau để ai đó có thể tìm được trang đó. Bạn có thể có rất nhiều đường dẫn intermediate trước khi chúng tới được sản phẩm cuối cùng.

Có lẽ sẽ dễ hiểu hơn khi sử dụng khái niệm trang intermediate, đây là một thực tiễn. Nếu một ai đó phải click qua 7 lớp của “faceted navigation” để có thể chọn được sản phẩm, họ có thể mất kiên nhẫn. Đó cũng là một điều bất bình thường trong công cụ tìm kiếm nếu chúng ta phải click qua 7 hay 8 lớp của một “faceted navigation” trước khi chúng ta có thể tìm được sản phẩm. Ở một vài trường hợp, sẽ là rất nhiều click và rất nhiều Pagerank bị chia cho những trang này mà không có một sản phẩm cụ thể nào người ta có thể mua được. Mỗi lần click là một cơ hội để một lượng phần trăm nhỏ Pagerank bị phung phí.

“Faceted navigation có thể là tốt với một số người sử dụng nếu bạn có thể quyết định những thứ bậc riêng bạn có thể phân loại các trang và cố gắng chắc chắn rằng “faceted navigation” là khá thấp. Những điều này có thể là một ứng dụng tốt giúp các công cụ tìm kiếm tìm ra được sản phẩm thực sự tốt hơn.

Câu hỏi: Nếu bạn có những trang có cùng sản phẩm hoặc về bản chất là cùng một loại sản phẩm với nhiều kiểu đặt hàng khác nhau, cách sử tốt nhất là dùng “canonical tag”?

Matt Cutts: Cũng có thể như vậy, hoặc bạn cũng có thể tưởng tượng việc sắp xếp lại vị trí của những tham số theo cách riêng của bạn. Nói chung, ý tưởng về “canonical tag” được thiết kế để cho phép bạn chỉ cho các công cụ tìm kiếm rằng 2 trang nội dung là như nhau. Bạn có thể không muốn phân biệt một bản đen và một bản trắng của một sản phẩm nếu bạn có 11 màu khác nhau cho sản phẩm này. Bạn có thể chỉ muốn có một trang sản phẩm mặc định mà sau đó trang này đủ thông minh để tự chuyển đổi sang các trang khác nhau.Thể hiện những biến đổi nhỏ trong một sản phẩm và có một rel=canonical để đi tới tất cả là một cách tốt để sử dụng “rel=canonical tag”

Câu hỏi: Hãy nói về những tác động đối với Pagerank, crawl và index của một vài công cụ cơ bản. Hãy bắt đầu với công cụ 301 Redirect yêu thích của chúng ta.

Matt Cutts: Nói chung 301 Redirect có thể chuyển được Pagerank. Đó có thể là một công cụ hữu hiệu để di chuyển giữa các trang trong một site, hoặc thậm chí là giữa các site. Rất nhiều người sử dụng chúng và dường như là nó hoạt động khá tốt vì nó có tác dụng dẫn tới trang cần thiết rất nhanh. Tôi dùng nó khi thử đi từ mattcutts.com tới dullest.com và quá trình chuyển đổi đó diễn ra khá nhanh. Thử nghiệm riêng của tôi đã chứng tỏ nó hoạt động khá thành công. Thực tế, nếu bạn truy cập vào site dullest.com ngay bây giờ, tôi sẽ chẳng vào được trang nào. Tất cả các trang đã di chuyển từ dullest.com tới mattcutts.com. Ít nhất đối với tôi, 301 Redirect làm việc như tôi mong muốn. Những trang yêu thích sẽ được chuyển tới một trang mới nếu như bạn truy cập trang theo kiểu chuyển trang và đó có thể là một công cụ vô cùng mạnh.

Câu hỏi: Có thể nói như bạn di chuyển từ một domain này tới một domain khác và bạn tự viết một câu để hướng dẫn công cụ tìm kiếm và những người sử dụng khác để đi từ một domain này tới một domain khác. Trong những trường hợp như thế này, có một vài mất mát trong Pagerank có thể sảy ra rất đơn giản bởi vì người sử dụng thực hiện một liên kết tới một site không liên kết nó tới một tên miền mới.

Matt Cutts: Đó là một câu hỏi hay và tôi không hoàn toàn chắc chắn về câu trả lời. Tôi có thể chắc chắn biết được sự mất Pagerank như thế nào. Tôi không hoàn toàn chắc chắn đội crawl và index sẽ xử lý thế nào với Pagerank chính vì thế tôi sẽ phải kiểm tra lại trường hợp này. (Chú ý rằng: trong một email, Matt thông báo rằng đây là trường hợp xảy ra trong thực tế. Pagerank bị mất khi thực hiện Redirect 301)

Câu hỏi: Hãy nói về 302 Redirect

Matt Cutts: 302 chỉ là giải pháp tạm thời. Nếu như bạn chỉ để một thứ vào một nơi trong một khoảng thời gian ngắn thì 302 là một lựa chọn thích hợp. Chúng sẽ không theo Pagerank nhưng chúng cũng có thể vô cùng hữu ích. Nếu một site chỉ làm một việc gì đó trong một khoảng thời gian ngắn, 302 có thể là một lựa chọn hoàn hảo.

Câu hỏi: Thế còn Server side redirects trả về “HTTP Status Code” hoặc là “200 Status Code”?

Matt Cutts: Nếu chúng ta chỉ thấy thông báo 200, chúng tôi thừa nhận rằng nội dung trả về ở địa chỉ URL mà chúng ta yêu cầu. Nếu nhà cung cấp dịch vụ đang làm một số kiểu URL rewrite kỳ lạ trên server side, chúng ta sẽ không thể biết được.Tất cả những gì chúng ta biết là chúng ra cố yêu cầu URL cũ, chúng tôi lấy được một vài nội dung và có thể index nội dung đó. Chúng tôi sẽ index nó dưới vị trí URL nguyên gốc.

Câu hỏi: Vì vậy bản chất của nó là giống như 302 đúng không?

Matt Cutts: Không hẳn là như vậy.Về bản chất, bạn đang lãng phí trên web server để trả về một trang có nội dung khác so với trang mà bạn yêu cầu. Như chúng ta quan tâm, chúng tôi nhìn thấy một liên kết, chúng tôi theo liên kết đó và chúng tôi yêu cầu nội dung. Bạn trả lại chúng tôi nội dung và chúng tôi index nội dung đó tại URL đó.

Mọi người có thể làm nhiều việc khác nhau ở trên server side. Bạn có thể tưởng tượng rằng một CMS được thực hiện trong một web server sẽ không thực hiện 301 hay 302, nhưng nó sẽ gây ra vài điều phức tạp và có thể có rất nhiều lỗi sảy ra.

Câu hỏi: Ông có thể nói một cách tổng quát về canonical tag?

Matt Cutts: Có rất nhiều điều phải nhớ ở đây. Nếu bạn có thể giảm số lượng nội dung trùng lặp bằng cách sử dụng kiến trúc của site , đó là một điều nên làm. Những trang mà bạn kết nối không cần thiết phải hoàn toàn là trang trùng lặp, nhưng chúng có thể là trùng lặp về khải niệm cùng với một sản phẩm khác hoặc một thứ nào đó có quan hệ gần gũi. Chúng ta có thể thực hiện Cross – domain, rel=canonical đã công bố tháng 12.

Có thể lấy ví dụ như, tôi có thể đặt rel=canonical cho tài khoản của trường cũ để tới trang mattcutts.com của tôi. Đó là một cách tốt để sử dụng rel=canonical nếu bạn không thể vào được web server để thêm vào redirects trong bất cứ trường hợp nào. Tuy nhiên, Hầu hết mọi người sử dụng chúng cho những nội dung trùng lặp để chắc chắn rằng bản canonical của trang đó được index hơn là một vài bản khác của một trang mà bạn không muốn index.

Câu hỏi: Vì vậy nếu một ai đó liên kết tới một trang có canonical tag, về bản chất liệu nó có thể đối xử giống như 301 đối với bản canonical của trang không?

Matt Cutts: Vâng, gọi đó là 301 của 1 người đàn ông nghèo nàn cũng không phải là một điều quá tệ. Nếu như web server của bạn có thể thực hiện trực tiếp 301, bạn có thể thực hiện được điều đó, nhưng nếu bạn không có khả năng truy cập được vào web server hoặc là có quá nhiều khó khăn để thiết lập 301 thì bạn có thể thực hiện rel=canonical.

Đó là một điều hoàn toàn tốt cho một trang tự liên kết sử dụng rel=canonical, và với Google thì nó thật sự hữu ích để thực hiện rel=canonical với mọi trang trong site của bạn. Mọi người nghĩ rằng nó rất tiết kiệm nhưng thật ra không hẳn là như vậy. Chúng ra tự hỏi bản thân về một trường hợp mà mỗi trang trong một site đều dùng rel=canonical. Miễn là bạn quan tâm tới việc chúng sẽ dẫn tới được đúng trang và sẽ chẳng có vấn đề gì cả.

Câu hỏi: Tôi nghĩ rằng tôi đã nghe thấy ông nói trong quá khứ rằng nó hơi mạnh để thực hiện một rel=canonical Chỉ dẫn. Về bản chất anh gọi nó là một lời gợi ý.

Matt Cutts: Vâng, nhóm crawl muốn coi những thứ đó như một lời gợi ý và phần lớn thời gian chúng tôi sử dụng chúng cho quảng cáo. Nếu bạn gọi nó là một chỉ dẫn, thì bạn sẽ rơi vào tình trạng phải tuân theo chúng, nhưng đội crawl và index muốn giành chúng như một quyền sau cùng để quyết định nếu như mà người chủ site đang tự hại mình và không nghe theo rel=canonical tag. Phần lớn thời gian, mọi người sẽ thấy tác dụng của rel=canonical tag. Nếu chúng ta có thể nói rằng họ không có ý làm như vậy, chúng ta sẽ có thể lờ nó đi.

Trở lại Lưu tin Top
- Theo: Internet

Tin mới hơn:
Tin cũ hơn: