2019년 2월 19일 – Google 도움말 행아웃 메모

So rel canonical is obviously a strong sign internal linking is also kind of a stronger signal, in that that's something that's under your control. So if you explicitly linked to those URLs and we think maybe you want them indexed like that. So in practice what what would probably happen here is we would index a mix of URLs some of them we would index the shorter version because maybe we find other signals pointing at the shorter version as well. Some of them we probably index with the UTM version and we would try to rank them normally as the UTM version.

In practice in search you wouldn't see any difference in ranking you would just see that these URLs might be shown in the search results. So they would rank exactly the same with UTM or without UTM and they would just be listed individually in the search results. And from a practical point of view that just means that in search console you might see a mix of these URLs. In the the performance report you might see kind of this mix. In the indexing report you might see a mix in some of the other reports. Maybe around the AMP or structured data if you use anything like that you might also see this mix. You might also see in some cases situation where it swaps between the URLs so it might be that we index it with UTM parameters at one point and then a couple weeks later if we switch to the cleaner version and we say, well probably this cleaner version is better, and then at some point later on or algorithm to look at it again and say well actually more signals point to the UTM version we'll switch back, that could theoretically happen as well.

So what I would recommend doing there is if you have a preference with regards to your urls make sure that you're being as clear as possible within your website about what version you want to have indexed. With UTM parameters you're also creating the situation that we'd have to crawl both of those versions so it's a little bit more overhead if it's just one extra version that's probably not such a big deal. If you have multiple UTM parameters that you're using across the website then we would try to crawl all of the different variations which would in turn mean that maybe we crawl, I don't know, a couple times as many URLs as your website actually has to be able to keep up with indexing. So that's probably something you'd want to avoid. So my recommendation would be really to try to clean that up as much as possible, so that we can stick to the clean URLs. To the URLs that you want to have indexed instead of ending up in this state where maybe we'll pick them up like this, maybe we'll pick them up like this, and in your reporting it could be like this, it could be like this. You have to watch out for that all the time. So keep it as simple as possible.

Question 21:56 - Will there be any ability to test and view desktop renders with screenshots in the URL inspection tool in search console?

Answer 22:05 - I get these kind of questions all the time. It's like will you do this in search console or will you do that. And in general we try not to pre-announce things so I don't really have any insight that I can give you there with regards to what will happen in the future. It does seem like something that is kind of a missing aspect of the tool in that it's focusing on mobile at the moment but it might be nice to actually test the desktop version as well. So I'll definitely pass that on to your team to make sure that that's on their radar somewhere.

Question 22:41 - On one website with a couple million pages we have a sidebar which has internal links in it and next to each there's a number which represents how many sub pages that link leads to. Sort of as an information informative visual aid and generating those numbers takes a lot of time is it okay to remove those numbers for the front page when Googlebot is detected?

Answer 23:08 - So Googlebot should be seeing the equivalent version of the page as users would be seeing. So if this is something that's useful for users I'd recommend showing it to Googlebot as well. It's something where if you're talking about the speed that it takes to to render these pages it's worth keeping in mind that we look at speed on kind of a holistic way we don't just look at the speed of a page as Googlebot is fetching that page when it comes to speed with regards to using speed as a ranking factor. For crawling of course having the pages that are available very quickly that helps us quite a bit so that makes sense to kind of make things fast for Google for crawling at least. One thing I'd recommend here though is try to avoid special casing Googlebot if if at all possible because it does mean that maintenance is a lot harder. If you're doing special for Googlebot then it's a lot harder to tell if Googlebot is seeing errors on the page and users are seeing normal content and Googlebot starts dropping those pages from search because of those errors. So ideally treat them a lot the same as users. One way you could do that here is to use some kind of JavaScript to just asynchronously load that extra information. So that's usually pretty easily doable probably less effort than cloaking to Googlebot in a case like this.

Question 24:47 - Does link equity pass through links on canonical pages or is it just ignored and everything flows to the canonical? So I think the question is more that you have one page it has a rel canonical pointing to a different page and the question is will those links on that original page kind of work pass PageRank or will only that pay the links on the specified canonical page pass PageRank?

Answer 25:18 - So from our point of view there are multiple things I've come into play here. I think first of all those pages should be equivalent if you're saying that there's a canonical for that page it should be equivalent to the final page as well. So it shouldn't matter which of these pages is used for forwarding links because you're essentially telling us these pages are the same we can treat them the same. So it shouldn't matter for our algorithms like if we pick up those links on that page or we pick up the links on the other page. So II would also assume there that not always kind of like in the other question with UTM parameters we would pick the URL that is specified as canonical as the one that we actually index. So if those links are different across versions of pages then that's something where we might not pass PageRank in the way that you're expecting. So all of that kind of comes together and from my point of view what I'd recommend there is just really making sure that those pages are equivalent. So that you don't have to worry about from where, which links are passing PageRank. But rather assume that it could be this page, it could be the other page, the rel canonical is a strong signal for us but it's not a directive that prevents us from using that page completely.

Question 26:50 - Is it a good idea to create a website for every country in the world?

Answer 26:58 - So the short answer there is no that's a terrible idea. Especially if you don't really have content that's unique to every country in the world. In particular if you're using hreflang between the different country and language versions. You need to keep in mind that hreflang does not make those pages rank higher in those countries it just swaps out those URLs. So you still have to be able to rank in those individual locations. Which means if you have one piece of content and you split it up across every country in the world and multiply it by every language then you'll have diluted your contents significantly across a large number of URLs. Which means that any piece of content there will have a lot more trouble being shown in the search results. Because instead of one strong page that we could show potentially worldwide, we have a ton of different pages that all show more or less the same content and none of them are particularly strong. So that's something where when it comes to an internationalization strategy I would strongly recommend getting help from people who have done this successfully for other websites. So that you can really weigh kind of the pros and the cons there. On the one hand you have the advantage of being able to target individual countries and languages with content that's really uniquely kind of specialized for them and on the other hand you have to weigh that if you're diluting the content too much then all of those versions will have a lot harder time to be visible in search. So on the one hand targeting well on the other hand kind of making sure that the versions that you do have available are strong enough to actually be be visible in search and my general thought there is to err on the side of using fewer versions rather than using more versions. So unless you have a really strong use case for having content specifically targeted for individual countries and I err on the side of well maybe one global website is better rather than splitting things up.

Question 29:25 - Can we use both rating schema and question-and-answer schema for question answers

Answer - 29:33 - Sure I don't see offhand why not. The main thing to keep in mind is that the structured data should be focused on the primary content of the page. So I don't know how exactly you would kind of combine the rating and the QA schema on a page but maybe it's something like you have questions and answers to a product and you have ratings at that product as well. That might be an option there but in general it's not that these types of markups are exclusive and you can only use one type you can combine multiple types of markup.

Question 30:41 - So our site had maybe like 5,000 Google visitors per day for several months now we're down to under 500. This was due to a sudden, just happened in one day, we think it's due to an automatic security penalty that we got removed within one business day and we just haven't seen any change within three weeks. So I'm wondering how long was something like that it might take to recover from and if there's anything else that would cause just a sudden one day drop like that?

We got a message in search console that social engineering content was detected. It turns out that was due to our email service provider there click track my software was was automatically flagged because I guess another clients was using it so we were we got a manual review and within a business day and they said it was ok but you know.

Answer 31:48 - Ok so if there was a manual review then that would be resolved. So it's not that there is kind of a hold back after manual review that says, oh we have to be careful with this website, but that should be resolved there. I know It's kind of hard to say just in a general case with regards to a site like that there there are sometimes algorithmic changes that happen that roll out we're bigger change happens with within a day or so. So that might also be playing a role here it might also be that there's something else kind of playing in with the site there. So what what I generally recommend doing is maybe starting a thread in the webmaster help forum with the URL of your site and some of the queries where you're seeing changes. So not just like we had this many queries and now it's like down to this but rather like people are searching for our company name they're still finding our company name but for this particular kind of query we're no longer visible anymore. So that that kind of thing is it's really useful to post in the webmaster help forum and usual also when when people can't find an answer for that, the experts there are able to escalate that on to us so that we can take a look at that as well.

Question 33:24 - So they have multiple sites in German for different countries and they have the a hreflang setup. It sounds like instead of properly. So this is just what the example URLs, it's hard to say but they're saying that they're not seeing a lot of indexing of these URLs across the different country versions so what what could be happening here?

답변 33:54 - 일반적으로 이와 같은 질문을 볼 때 알고리즘은 이 페이지를 보고 이 페이지가 본질적으로 서로 중복된다고 말합니다. 그래서 우리는 이러한 버전 중 하나를 색인화할 수 있고 모두 동일하기 때문에 사용자에게 해당 버전을 보여줄 수 있습니다. 그래서 특히 독일어에서 이것은 꽤 많이 볼 수 있는 것입니다. 다른 언어에서는 여러 스페인어를 사용하는 국가나 영어뿐만 아니라 내용이 본질적으로 동일하고 대상을 대상으로 하는 스페인어에서도 비슷할 것이라고 상상합니다. 다른 나라. 그래서 여기에서 일어나는 일은 인덱싱의 관점에서 우리는 아마도 적어도 잠재적으로 이러한 URL을 함께 접을 수 있으므로 여러 독일어 버전이 하나의 독일어 버전을 선택하고 이것이 hreflang 마크업이 있는 독일어 버전의 표준이라고 말합니다. d 여전히 다른 URL을 표시할 수 있습니다. 그래서 우리는 아마도 스위스 독일어 버전의 색인을 생성할 수 있고 독일에 있는 사용자가 검색하는 경우 검색 결과에서 해당 URL을 독일어 버전과 바꿀 수 있습니다. 그러나 검색 콘솔의 인덱싱 보고서에서는 해당 URL이 표준으로 선택한 스위스 버전에 대해서만 인덱싱되는 것을 볼 수 있습니다. 따라서 독일어 버전의 경우 실제로는 이러한 페이지가 정말 똑같더라도 문제가 없을 수 있습니다. URL을 교체하고 있기 때문에 사용자가 올바른 버전으로 이동하는 데 거의 문제가 없고 어려움이 있을 수 있기 때문입니다. 제목에 내용이 있거나 해당 페이지에 가격 또는 기타 구조화된 데이터가 있는 경우 독일 사용자가 검색할 수 있다는 점에서 사용자를 혼란스럽게 할 수 있습니다. 우리는 독일어 URL을 표시하지만 스니펫에는 스위스 어딘가에 가격으로 통화. 사람들에게 혼란을 줄 수 있으므로 한편으로는 일반적으로 두 가지 접근 방식이 있습니다. 접근 방식을 취하고 이러한 URL을 함께 접는 것이 괜찮다고 말할 수 있습니다. 그런 식으로 유로를 조금 더 강하게 만드는 것은 괜찮습니다. 그런 다음 거기에 가서 이 페이지가 모든 독일어 버전을 가로지르는 일반 페이지인지 확인하여 실제로 색인이 생성되는 URL이 저에게 중요하지 않다고 말할 수 있습니다. 다른 접근 방식은 이러한 URL이 별도의 선행 URL로 명확하게 표시되도록 하는 것입니다. 따라서 콘텐츠가 서로 다른 언어 버전에서 실제로 크게 다른지 확인하여 시스템에서 이 페이지를 볼 때 "이것은 하나의 독일어 페이지이고 이것은 다른 독일어 페이지입니다. 두 언어 사이에 hreflang 링크가 있습니다."라고 말합니다. 따라서 해당 URL을 교환할 수 있지만 자체적으로 개별적으로 색인을 생성해야 하는 고유한 페이지입니다. 그래서 그것들은 일종의 두 가지 접근 방식입니다. 한편으로는 함께 접을 수 있고 다른 한편으로는 이렇게 말할 수 있습니다. 저는 이것들을 명시적으로 분리하기를 원합니다.

질문 37:00 - 브랜드가 국제적인 입지를 갖고 있고 특정 지역에서 폐쇄되면 무엇을 조언하시겠습니까? 주요 사이트를 리디렉션해야 하는 다른 국가를 대상으로 하는 사이트는 어떻게 합니까?

답변 37:14 - 본질적으로 이것은 일종의 사이트 마이그레이션 상황입니다. 하나의 국가 사이트가 있고 이 사이트를 더 이상 사용할 수 없다고 말하는 경우 다른 버전으로 리디렉션하겠습니다. 당신이 할 수 있는 일입니다. 당신이 정말로 할 수 없는 것은 우리가 특정 국가에서 이 사이트를 보여서는 안 된다고 우리에게 알려주기 위해 검색에서 지정하는 것입니다. 따라서 독일어 버전을 함께 접을 수 있고 독일 오스트리아 스위스처럼 모두 괜찮은 하나의 독일 웹 사이트여야 하지만 스위스 사용자에게 내 사이트를 보여주고 싶지는 않지만 그렇게 할 수는 없습니다. Google이 스위스에서 내 사이트를 표시하지 않는다고 말할 수 있는 메타 태그가 없습니다. 따라서 기껏해야 해당 국가의 사용자가 사이트에 액세스하지 못하도록 차단할 수 있지만 해당 국가의 검색 결과에 표시하지 않도록 Google에 말할 수는 없습니다.

질문 38:18 - 그것이 제 질문이었습니다. 당사 웹사이트는 영어로 되어 있으며 다른 국가와 고유한 콘텐츠를 보유하고 있습니다. 따라서 비즈니스 결정으로 인해 특정 지역을 폐쇄하고 있습니다. 따라서 사이트에 대한 리디렉션을 수행하면 내 기본 웹 사이트에 영향을 줄까요? 부정적인 영향을 줄까요 아니면 긍정적인 영향을 줄까요? 내 말은 현재 우리가 볼 수 있는 공통 페이지가 있는 모든 하위 집합에 걸쳐 이 hreflang이 있다는 것을 의미합니다. 즉, 한 특정 국가에서는 하나의 제품을 제공하고 다른 국가에서는 다른 콘텐츠와 모든 지역 로컬 콘텐츠로 단일 제품을 제공한다는 의미입니다. 그래서 그 페이지들은 어떻게 되는지 궁금합니다. 해당 페이지를 내 기본 사이트로 리디렉션하면 내 기본 페이지가 해당 특정 지역의 순위를 정합니까?

답변 39:19 - 그것은 잠재적으로 일어날 수 있지만 다시 말하지만 그건 당신이 정말로 통제할 수 있는 것이 아닙니다. 따라서 해당 페이지가 여전히 존재하는 경우 해당 페이지를 리디렉션하는 경우 해당 위치에서도 순위가 매겨질 수 있습니다. 메타 태그가 없다고 말할 수 없거나 내 웹사이트가 색인이 생성되어야 하지만 이 특정 항목에 표시되지 않아야 한다고 말할 수 있습니다. 국가.

질문 39:50 - Google은 다양한 틈새 시장에서 사용자를 즐겁게 하는 모범 사례에 대한 UX 플레이북을 제공합니다. 이것들은 순위의 일부로 간주됩니까 아니면 이에 대한 통찰력을 줄 수 있습니까?

답변 40:02 - 내가 아는 한 이러한 UX 플레이북은 광고 팀에서 내놓았고 더 중요한 문제는 이것이 UX 모범 사례이자 웹사이트에서 해야 할 좋은 일이며 반드시 우리가 해야 하는 것은 아닙니다. d 말하자면, 이것들은 순위에 영향을 미치지만 분명히 사용자에게 잘 작동하는 좋은 웹사이트를 만들면 간접적으로 순위에 영향을 미칠 수 있습니다. 그러나 이러한 UX 플레이북을 살펴보고 특히 이를 순위 요소로 사용한다고 말하는 것은 아닙니다.

질문 40:38 - 민감한 주제를 대상으로 하는 콘텐츠와 혼합될 때 제휴사 링크의 영향은 무엇입니까? 공격적인 수익 창출은 특히 사용자에게 제휴 링크가 공개되지 않고 수익 창출에 중점을 두는 것이 사용자에게 훌륭한 콘텐츠를 제공하는 것보다 더 중요한 경우 문제가 될 수 있다는 것을 알고 있지만 건강, 의료, 금융과 같은 주제에서는 그것이 어떻게 작동할지 궁금합니다. 등.?

답변 41:05 - 일반적으로 이것은 우리가 명시적으로 사이트에 들어가지 않고 제휴 링크처럼 보이는 링크가 있으므로 이 웹사이트를 품질이 낮은 것으로 취급하지 않는다는 것을 알고 있는 한 아닙니다. 일반적으로 제휴 웹사이트와 관련하여 제가 볼 수 있는 주요 문제는 웹사이트 품질이 낮은 경향이 있다는 것입니다. 따라서 체크아웃 흐름이 어디에 있느냐의 문제가 아니라 전반적으로 콘텐츠의 품질이 낮은 경우가 많으며 우리 알고리즘이 파악하고 말할 수 있는 콘텐츠의 품질이 낮기 때문에 아마도 그렇지 않을 것입니다. 가장 관련성이 높은 결과가 검색 결과에 표시되며 실제로 고품질의 제휴 웹사이트도 있을 수 있습니다. 그래서 그것은 제휴 링크가 있는지 없는지에 대한 문제가 아니라 웹사이트의 나머지 부분은 어떻습니까? 이것은 사용자에게 표시하는 것과 관련이 있습니까? 아니면 문제가 있을 수 있습니까? 나는 적어도 내가 아는 한, 그것은 전반적으로 적용될 것이라고 생각합니다. 그래서 웹사이트의 특정 주제 영역이 무엇인지는 별로 중요하지 않지만 일반적으로 정말 좋은 제휴 사이트도 있고 정말 끔찍한 것도 있습니다. 제휴 사이트. 따라서 사이트가 좋은가 아니면 나쁜 사이트가 더 중요합니다.

질문 42:35 - 가져오기 및 렌더링이 이전 검색 콘솔에서 더 이상 사용되지 않고 URL 검사 도구로 대체되어 Googlebot이 페이지를 보는 방식과 사용자가 보는 방식에 대한 시각적 비교를 나란히 포함하도록 UL 검사 도구가 업데이트됩니까? 그들을 볼 수 있습니까?

답변 42:53 - 다른 질문과 마찬가지로 사전 공지를 하지 않으려고 하는지 잘 모르겠습니다. 앞으로 일어날 일에 대해 구체적으로 말씀드릴 수 있는 부분은 아닙니다. 또한 우선 순위 지정과 관련하여 살펴보도록 팀에 전달하게 되어 기쁩니다. 실용적인 관점에서 나는 대부분의 사이트가 페이지가 검색 엔진용으로 렌더링될 수 있는지 확인하는 데 꽤 능숙하기 때문에 이 비교가 요즘에는 덜 유용하다고 항상 느꼈습니다. 적어도 내가 본 사이트는 좋은 편에 속하는 경향이 있습니다. 따라서 특히 사이트가 검색 엔진에 실제로 사용되지 않았을 때 실제로 큰 페이지를 렌더링하려고 시도했지만 요즘에는 자바 스크립트가 차단되는 경우와 같이 그것이 실제로 그렇게 큰 문제인지 모르겠습니다. robots.txt, 그런 종류의 것들이 수년에 걸쳐 크게 바뀌었다고 생각하지만 비용을 지불하게 되어 기쁩니다. 팀에 전달되고 팀에서 우리가 거기에 정말로 필요한 문제가 있는지 다시 확인하게 될 것입니다.

질문 44:12 - 거부 링크가 순위를 높일 수 있습니까?

답변 44:17 - 맙소사, 정말 큰 질문입니다. 따라서 이론적으로 귀하의 웹사이트가 시간이 지남에 따라 귀하가 구입한 링크 또는 다른 사람이 귀하의 웹사이트에 대해 구입한 링크와 관련하여 직접 조치로 강등된 경우입니다. 이전 SEO일 수도 있고 해당 회사에 근무하기 전에 설정한 것일 수도 있습니다. 그런 다음 거부 도구를 사용하여 시스템에서 해당 링크를 제거할 수 있습니다. 그런 다음 재검토 요청 양식을 사용하여 이 변경 사항에 대해 알릴 수 있습니다. 그런 다음 수동 웹스팸 팀이 살펴보고 현재 상태가 괜찮은지 다시 확인합니다. 현재 상태가 깨끗하면 해당 수동 조치를 해결하고 일반적으로 웹 사이트의 순위가 자연스럽게 다시 올라갈 수 있습니다. 그래서 그것은 많은 경우에 웹사이트가 약간 올라가고 어떤 경우에는 순위가 매겨지는 부분이며 이러한 부자연스러운 링크가 처음에 웹사이트를 부자연스럽게 지원했기 때문일 수도 있습니다. 따라서 이러한 링크를 제거하면 일종의 자연 상태인 이 지원이 사라질 수 있습니다. 따라서 더 짧은 대답은 여기에 예 또는 아니오가 없다는 것입니다. 링크 거부는 귀하의 웹사이트에 대한 링크로 우리가 보는 것을 변경하고 귀하의 웹사이트에 긍정적 또는 부정적으로 영향을 미칠 수 있습니다. 따라서 일반적으로 거부 도구와 함께 내 권장 사항은 링크와 관련하여 수동 조치가 있고 해당 링크를 제거할 수 없는 경우 또는 링크를 볼 때 깨닫는 경우에 이것을 사용하는 것입니다. 오, 우리가 2년 전에 그랬을 수도 있고 웹 스팸 팀은 눈치채지 못했지만 우리의 행위를 정리하고 정리해야 할 때일 수도 있습니다. 그런 다음 거부 도구를 사용하는 것이 합리적입니다. 나는 이것을 무작위로 사용하지 않고 이것이 이상한 링크라고 잘 말하고 그들과 연결하고 싶지 않습니다. 나는 그런 일이 일어날 것 같지 않은 그런 것들을 제거할 때 Google이 내 웹사이트의 순위를 더 좋게 할 수 있기를 바랍니다.

질문 46:27 - John 여기에서 거부를 기반으로 질문을 해도 될까요? 그래서 우리는 때때로 경쟁자일 수도 있다고 추측하고 있습니다. 말 그대로 한 곳에서 1.1 또는 1.2 링크가 우리 홈페이지로 전송되는 것을 보게 될 것입니다. 완전히 주제를 벗어난 아일랜드의 악기 수리 사이트, 우리가 하는 일과 전혀 관련이 없습니다. 모든 링크를 거부할 수 있는 도구나 능력이 없습니다. 그러면 사이트를 거부하는 것이 가장 좋습니까?

답변 47:01 - 물론 할 수 있습니다. 네, 그게 바로 거부 파일의 도메인 항목이 사용하는 용도입니다. 그런 식으로 수백만 또는 수천 개의 링크가 모두 이 사이트의 모든 것을 말할 수 있는 것과 같습니다. 저는 그와 아무 관련이 없습니다. 일반적으로 이 완전히 임의적인 사이트 링크가 표시되는 경우 해당 사이트가 해킹당했을 수 있으며 어떤 이유로든 누군가가 웹 사이트를 해킹할 때 해당 링크를 모두 삭제하기로 결정했으며 일반적으로 우리는 이를 선택하는 데 꽤 능숙합니다. 그리고 그들이 우리 시스템을 해킹하기 전에 상태를 유지하려고 합니다. 따라서 아마도 우리는 이미 해당 링크를 무시하고 있을 것입니다. 해킹된 콘텐츠가 아니라 이전의 웹사이트를 색인화하거나 색인을 생성할 수도 있습니다. 이러한 종류의 해킹은 정말 일반적이고 우리는 이를 처리하기 위한 약간의 연습이 있기 때문에 일반적으로 너무 많이 걱정하지 않을 것입니다. 그러나 이것에 대해 걱정한다면 오 이것은 정말 미친 짓이고 악기 수리 링크는 아마도 당신이 말하는 것과 같은 것이 아니라고 생각합니다. 오, 내가 바이올린과 관련되어 있다면 내 웹사이트가 죽게 될 것입니다. 아마도 성인용 콘텐츠는 귀하가 더 조심해야 하는 부분일 수 있습니다. 그러면 저는 거부 파일을 사용하여 제출할 것이며 이러한 내용은 고려되지 않을 것이라고 확신합니다.

질문 48:44 - 이 URL에 대한 두 가지 간단한 질문입니다. 전자 상거래 웹사이트의 카테고리 URL로 일종의 보기-올 매개변수가 있습니다. 기본적으로 우리의 문제는 URL에 매개변수가 없는 버전에 대한 표준이 있다는 것입니다. 웹사이트 전체에 걸쳐 매개변수가 없는 버전과 연결되어 있습니다. 매개변수가 없는 사이트맵에 있지만 어떻게든 Google은 이것이 정식 버전이 아니라고 결정하고 모든 신호가 다른 버전을 가리키고 있으며 그다지 작용하지 않는다고 생각합니다. 나는 우리의 모든 신호가 같은 방향을 가리키고 있는데 왜 Google이 우리 버전을 선택하지 않는지 이해할 수 없습니다.

질문 48:24 - 잘 모르겠습니다. 직설적으로 말하기 어렵습니다. 따라서 염두에 두어야 할 한 가지는 모바일 우선 인덱싱 아래에 있다는 것입니다. 그래서 아마도 모바일 버전은 약간 다를 수 있습니다. 아마도 rel canonical이 있을 수 있습니다. 아마도 rel canonical을 변경하는 JavaScript와 함께 무언가가 있을지도 모릅니다. 그러나 그것은 항상 염두에 두어야 할 것입니다. 따라서 브라우저에서 테스트할 때 모바일 보기를 다시 확인하지만 이전의 다른 질문과 마찬가지로 종류가 무엇이든 우리가 잘 결정하고 있는 다른 이유가 무엇이든 간에 실제로 이것이 더 깨끗할 수도 있습니다. 버전.

질문 50:33 - 어느 곳에서도 연결되지 않고 내부 링크가 이를 가리키지 않는다는 것을 알고 있는 경우. 사이트맵을 만들지 않을 것이며 Google에 대한 URL 검사를 통해 올바른 표준을 볼 수 있습니다. Google은 우리가 태그를 지정하는 것이 아니라 Google에서 선택한 표준이라고 말했습니다. 그래서 그것이 어떤 영향을 미칠지 모르겠지만, 다른 페이지에도 영향을 미칠 수 있는 우리가 놓치고 있는 무언가가 있지 않을까 걱정됩니다.

답변 51:11 - 예, 살펴봐야 할 지 모르겠습니다. 일반적으로 동일한 내용이면 순위가 동일합니다. 그래서 거기에서 아무 것도 바뀌지 않습니다. 나에게 헤어케어 제품으로 뇌물을 주는 것이 특히 유용할지 모르겠지만 나는 모르겠다. 그래서 제 말은 여러분이 전체 보기 페이지를 갖고 있고 페이지의 다른 버전이 있는 상황이라는 것을 의미합니다. 이것이 우리가 유지해야 하는 전체 보기 버전이라는 신호를 포착할 수 있다는 것입니다. 페이지 매김이나 이와 유사한 것일 수 있기 때문에 다른 것 대신에 하나를 사용합니다. 언급할 가치가 있는 또 다른 사항은 일반적으로 전자 상거래 사이트에 대한 모범 사례와 관련된 문서를 작성하고자 한다는 것입니다. 따라서 우리가 전자 상거래 사이트에서 잘 사용하고 있는 이와 같은 이상한 일을 만난다면 콘텐츠와 페이지 매김, 필터링 및 보기가 모두 포함된 카테고리 페이지가 있는 경우가 많습니다. 피드백을 받고 싶습니다. 따라서 예는 전자 상거래 사이트에 관한 일반적인 질문일 수 있으며 이 모든 것이 정말 유용할 것입니다. 이상적으로는 트위터를 통해 보내어 거기에서 수집할 수 있습니다. 트윗을 시작했고 일부와 함께 뭔가를 만들 수 있기를 바랍니다. 전자 상거래 사이트와 관련하여 인덱싱 및 크롤링을 확인하는 방법에 대한 모범 사례를 추측합니다. 이상적으로 작동합니다.