Google搜尋與購物:產品變體的探討與橋接差距

結構化數據標記的衝突要求

長久以來,這種差異也蔓延到了雙方維持的一些結構化數據標記</a>要求中。這些不一致通常會導致即使我們為Google搜索配置的產品和優惠標記符合要求,Google商家中心卻可能不認可;反之亦然。我們往往只能通過複製部分標記並稍微改動其模型來解決這一問題。<br/><br/>這迫使我們發布冗餘資訊,因為谷歌的不同部門沒有足夠考量彼此的需求——把理清和處理這混亂局面的責任推給了我們。

Google不同部分終於開始架起溝通的橋樑

經過一段時間,涉及的各方谷歌團隊開始統一他們對結構化數據標記</a>的要求。這還是在谷歌購物宣布將包含有機搜索結果之前,這是向前邁出了非常重要的一步,因為這意味著產品終於可以免費</a>進入谷歌購物了。對於我們這些需要生產他們所需的結構化數據</a>但又常常在實現方法上迷失方向的人來說,以及那些一直想被納入谷歌購物卻又負擔不起的人來說,真是太好了。<br/><br/>這表明了立場的轉變,其影響我們早在2019年中就已經在schema.org上看到發生了,當時第一批關於詞彙變更的請求正在接收並公布中。為了證明這點,以下列出自那刻起頭一年內添加或修改的類型、屬性和枚舉列表: 2019-07-01, schema.org 發布 3</a>.8 版:ProductReturnPolicy(產品退貨政策), gtin。 2020-01-21, schema.org 發布 6.0 版:MerchantReturnPolicy(商家退貨政策)。<br/><br/> 2020-05-01, schema.org 發布 8.0 版:OfferShippingDetails(提供運輸詳情),deliveryTime(送達時間),doesNotShip(不提供運輸),shippingDestination(運輸目的地),shippingLabel(運輸標籤),shippingRate(運價),shippingSettingsLink(運送設置連結),transitTimeLabel(運輸時間標籤),ShippingDeliveryTime (送貨時間),DefinedRegion (指定地區),PostalCodeRangeSpecification (郵政編碼範圍規範)。 2020-07-21, schema.org 發布 9.0 版:size (大小),pattern (模式),ProductGroup (產品群組),variesBy (多種變化),hasVariant (具有變體),productGroupID (產品群組ID),isVariantOf (是…的變體),ProductCollection (產品集合)。 2020-09-07, schema.org 發布 10.0 版:hasEnergyConsumptionDetails(具有能源消耗細節), EnergyConsumptionDetails(能源消耗細節), hasEnergyEfficiencyCategory(具有能效分類), EnergyEfficiencyEnumeration(能效枚舉), EUEnergyEfficiencyEnumeration(EU能效枚舉), EnergyStarEnergyEfficiencyEnumeration(Energy Star 能效枚舉), energyEfficiencyScaleMax(最高能效等級), energyEfficiencyScaleMin(最低能效等級)。<br/><br/> 欲查看完整更新列表可訪問schema.org 的版本發布頁面(目前已更新至23</a>.0版)。

障礙被語義建築塊取代

自那之後,GMC(Google Merchant Center)的許多產品特性已被轉化為全新的schema.org類型、屬性及數據模型。這是一個認真的嘗試,讓我們能夠通過schema.org注釋來表達所有在GMC產品資料流中能表達的內容</a>—從而減少對谷歌資料流的依賴,同時也為我們提供了一種實現相同目標的新方法。這是一個尚未完成的過程,但到目前為止,它已不再僅僅是理論上的探索。<br/><br/>在過去幾年中,我們都見證了發生的變化,包括谷歌搜索和谷歌購物結果、Google Merchant Center以及谷歌結構化數據</a>文檔和Google Search Console報告方面的改動。然而未來還有更多變革即將到來,最值得注意的大問題(對電子商務</a>站點而言可謂SEO</a>領域裡的巨大挑戰)無疑是:如何</a>通過谷歌搜索高效支持產品變體。

介紹一個(有點新的)基本拼圖部分

在2020年7月新增至schema.org詞彙表中,卻直到2022年9月才出現在GMC的文檔與Google結構化數據</a>功能指南中的一項GMC產品屬性轉換:[item_group_id] 對應 schema.org 中的 inProductGroupWithID 屬性。乍看之下,這個屬性似乎解決了問題,因為它允許我們創建描述與GMC XML提要相同關係的產品標記: ```json { ′@context′: ′https://schema.org′, ′@type′: ′Product′, ′name′: ′黃色夏季T恤XL碼′, ′description′: ′適合夏日穿著的加大號黃色T恤。′, ′image′: ′https://example.com/content/yellow-summer-t-shirt.jpg′, ′inProductGroupWithID′: ′abc123</a>′, ′gtin′: ′8710123</a>456789′, ′color′: ′yellow′, // 確保也查看新的 size 屬性。<br/><br/>這是一個很重要的特性。 ′size′: { ′@type′: ′SizeSpecification′, ′name′: ′XL′, // 使用美國尺寸系統 // 大碼及高人群尺寸分組 ′@type′: [′https://schema.org/WearableSizeSystemUS′, https://schema.org/WearableSizeGroupBig′, https://schema.org/WearableSizeGroupTall′] }, // 提供信息 offers: { ′@type′:′Offer′, url′:′https://www.example.com/products/summer-t-shirt?size=xl′, priceCurrency:′USD′, price:19.99, itemCondition′:′https://schema.org/NewCondition′, availability′:′https://schema.org/InStock′ } } ``` 注意:您需要將 inProductGroupWithID 屬性添加到屬於同一組別的所有產品變體詳情頁面的標記中——儘管這正是下一個問題出現的地方。

XML Feed與語義註釋之戰 – 效率之爭

很多人可能沒有深思,但實際上,透過網頁來收集結構化數據標記</a>——而且是在整個網路規模上——其實是一項極其複雜且耗資的任務。這意味著谷歌需要投入相當大的努力(和金錢)來累積所有這些信息。事情還沒完。<br/><br/>收集了所有這些信息之後,谷歌還得整合所有產品變體信息,弄清楚各式各樣的產品如何</a>互相對應。哦,還有一點不得不提的是它必須處理海量存在於網頁中的標記錯誤——這讓處理該等信息更加困難重重。因為谷歌也需要持續更新商品的可用性、價格、運費等資訊——而這類資訊通常變動無常。<br/><br/>對於你網站上每一個單品詳情頁面,谷歌都得反復做同樣的工作,永無止境。

規範URL對於保持產品變體信息更新而言是逆效果的

或許你還不知道,無論是Google搜尋還是Google商家中心(GMC),它們在產品變體管理和設定典範URL方面都有一些指南。這些內容</a>在他們的結構化數據</a>功能指南及商家中心文檔中都有提及——我強烈建議你去閱讀這些資料。然而,如果你曾涉足技術性SEO</a>領域,這些信息對你來說並不陌生。如果真的如此,那麼你可能也意識到了Google爬蟲會明顯減少對被標記為典範的URLs的抓取次數,相比之下更多地抓取<pre><code>&lt;link rel=′canonical′&gt;</code></pre>所指向的URLs。隨著典範參照存在時間的增長</a>,其抓取率會進一步降低。原因在於這向Google搜索發出了一個明確信號——表明此處可能有重複內容</a>以及該重複內容</a>最關鍵版本所在位置。這使得Google更容易判斷哪些URLs需要更多關注——這點對Google至關重要,因為它只能分配有限資源來爬取你的站點。 这种做法对于 Google 搜索来说效率极高,但对于你而言却可能并非如此;例如那些曾经缺货一段时间现已重新上架等待售卖的产品——可别高兴太早!因为 Google 的爬虫程序回头重新检查您产品页面的速度可谓“从容”。这就意味着您在商品搜索结果中显示缺货状态持续停留在第三页甚至更深层次混乱之中不见天日。哦,还有那些在 Google 购物里标记为缺货状态的无索引商品列表怎么样了?这对于您又起了什么作用呢? 当然啦,您可以通过修改网站地图XML文件中相关URLs 的 <pre><code>&lt;lastmod&gt;</code></pre> 来进行变革, 如果产品数量少于500个, 这确实很有效;但当我们谈论成千上万(甚至更多)产品URLs时, 那点儿<pre><code>&lt;lastmod&gt;</code></pre>更新就像海洋里掉进去几滴雨水,并没有太大帮助。而且,在这种情况下被设为典范链接(URL) 的页面会被爬虫程序获取得更加罕见。结构化数据标记更新 Google 购物和 Google 搜索结果?好吧, 似乎这个方法飞窗而去了。

GMC Feed – 仍是通知Google產品更新最有效的方式

谷歌只需要获取有限的商品数据源。因此,它们为谷歌提供了一个更简易且成本效益高的方式来获得完整和最新的商品数据集合。我并不是说这些数据源中包含的信息总是完美无缺。<br/><br/>(惊讶吧!它们往往看起来就像炸开的彩色纸屑一样。)但至少谷歌不必预先爬遍整个域名来获取全貌。这种情况引出了下一个话题:我们推出了一个新的类别来帮助我们在网站上更集中的位置打包部分信息——可能就是你产品变体链接标签指向的相同位置。<br/><br/>这样做可以使谷歌在未爬取每个单品之前,更容易地抓取到一些关键信息片段,因为所有产品都能指向那个集中版本的结构化数据标记。由于你规范化目标URLs被更频繁地爬取,你在产品搜索结果上也能实现较快速度上的更新,从而大幅缩小商品数据源和结构化数据标记之间效率差距。

但首先,需要提醒一句話

我強調「可能」這個詞,是因為在Google正式發布其公告之前,沒有人能準確知道它將如何</a>實施這一新舉措及其利用方式——也無法預測其他數據使用者(例如Bing、Facebook、Pinterest等)會如何</a>反應,或者可能根本不做出任何回應</a>。這意味著,在Google發表相關公告前,你應當對那些自稱已知道結果及隨時間演變情形的人持保留態度。即使schema.org和Google的團隊自己都不能確定,所以別讓其他任何人告訴你他們知道答案。<br/><br/>然而有一點可以肯定:很多未來的發展將極大地依賴於顧客和同行的反饋。這意味著它很可能也會經歷一個非常迅速靈活的演化過程。就像Google已經鑽研了好多年,但仍未把每一個細節處理完畢——為了保留某些調整空間——這一點足以作證。<br/><br/>

在ProductGroup宣布前所需準備的事項

考慮到我長期參與了schema.org上關於這個話題的討論,再加上一些谷歌員工也非常活躍地參與其中,我對至少嘗試為你提供一些洞察頗有信心,讓你理解未來(不久的)將會發生的事情背後的原因和方式。通過這樣做,我希望能給你足夠的時間在谷歌宣布之前開始研究這件事——因為很有可能實現這種標記(markup)會伴隨著一些技術挑戰。我估計你需要一段時間來熟悉所有相關內容</a>,以便確定在事情成為現實之前需要做什麼準備。<br/><br/>例如:你需要的數據可以拿到手嗎?你的系統能否在正確時刻產生標記所需的全部部分?在主要URL上提供的標記能否和其他產品變體URL上的不同?如果你有數據源(feed),怎麼保證你的標記和數據源中的數據保持同步?等等。如果你沒有為此做好準備,當谷歌最終宣布消息時,很可能會措手不及,然後陷入競爭者間互相追趕、拼命趕上對手步伐的混亂局面。

告訴Google如何找到ProductGroup資訊的位置

隨著我們繼續使用前面的範例進行標記工作,您將會發現</a>要讓消費者知道存在包含產品組(ProductGroup)信息的頁面其實非常容易。我們只需在所有屬於某一產品組的商品變種詳情頁面上新增幾行標記即可。 例如,以下是一個黃色夏季大號T恤衫的產品標記示例: ```json { ′@context′: ′https://schema.org′, ′@type′: ′Product′, ′name′: ′黃色夏季T恤衫XL′, ′description′: ′適合夏日穿著的超大號黃色T恤衫。<br/><br/>′, ′image′: ′https://example.com/content/yellow-summer-t-shirt.jpg′, ′inProductGroupWithID′: ′abc123</a>′, ′gtin′: ′8710123</a>456789′, ′color′: ′yellow′, // 請特別關注新加入的size屬性,它十分重要。 ′size′: { ′@type′: ′SizeSpecification′, ′name′: ′XL′, // 尺寸系統使用美國可穿戴尺寸系統 // 尺寸群組涵蓋了′大碼′與′高身材′ ... }, // 提供資訊部分也包括了價格、存貨狀況等詳細數據 ... ′isVariantOf′: { ′@type′: ProductGroup′, ′productGroupID′:′abc123</a>′, ′url′:′https://www.example.com/products/summer-t-shirt′ } ``` 然而,在schema.org上的討論中,有人建議「這類數據的消費者」可以允許更精簡形式來注釋isVariantOf信息: ```json ′isVariantOf′:′https://www.example.com/products/summer-t-shirt′ ``` 原因是從發布者角度來看,這種方式製作起來更為容易,同時仍能達到相同效果:提供指向真正包含產品組信息入口點的參考連接,無需在多數頁面上添加大量冗贅標記。希望谷歌能聽取這項建議。<br/><br/>(註:它在聽取建議方面做得比很多人認為的好)。至於在哪裡發布產品組信息——正如我之前所表達,我預計谷歌會告訴我們,在那些屬於某一群組且具有規範URL的商品變種上發布標記以符合其目前關於如何</a>處理商品變異URL指南。

一些充滿希望的推測

或許有朝一日,我們不再需要為每一種商品變體都選擇一個典範網址&mdash;這可是件既麻煩又技術上複雜的工作。好像這項任務還不夠頭大似的,事實上許多電商平台並未提供這類功能得心應手。相反地,很多平台只配備了某種類似於「產品群組」的頁面,表現為一個產品詳情頁面,在等待用戶操作前不會設定任何可變屬性。<br/><br/>如果你能在唯一可用的URL(每個產品群組各有其對應URL)上直接發佈產品群組標記,并且包含所有商品變體信息,那豈不美哉?想象一下如果我們能做到這點而又不失去任何豐富的搜索結果&mdash;那就像因為試圖保持透明、完整呈現你的網頁數據故事而被處罰一般!誰知道;或許有天我們真能達成這目標。如今至少有了schema.org中的ProductGroup類別,在理論上提供了一個可行解決方案</a>。時間會證明Google是否也看到它的價值和必要性。<br/><br/>′行了,Jarno, 別再廢話連篇!快點告訴我怎麼利用產品群組吧。” ……好啦好啦好啦,聽見你了。男孩女孩們,拿穩帽子,出發囉。<br/><br/>

深入了解ProductGroup:其成員藍圖

在深入探討一個圖解式標記範例之前(這可能並未涵蓋你對產品的所有描述),讓我首先解釋一下ProductGroup第二功能背後的理念:它是屬於某個產品組的各種產品變體的原型/模板/藍本。這意味著,幾乎所有你添加到產品組中的屬性(及其值)都會被其產品變體繼承——同時還能通過variesBy屬性來表達哪些屬性是產品間有差異的。如果消費者按預期使用,這相當巧妙,因為它避免了我們必須添加大量重複信息。<br/><br/>例如,在我的範例中,由於產品組具有屬性-值對“材質”:“棉”,所以產品組中的所有產品變種自動繼承相同的屬性-值對。這意味著所有產品變種的主要材質將是棉,無需將該信息添加到每一件產品變種中。同時,我們還可以告知消費者,產品變種在顏色和大小上有所不同,并且他們可以期待在產品變種的標記中找到該信息。<br/><br/>這使得實體間有很多交叉引用——而不必使用大量uri/iri標識符(通過JSON-LD中的@id、Microdata中的itemid、RDFa中的resource)。如果你認為這不會有太大區別,再想一想;重複自身的商品信息很快就會累積起來。僅僅是在我的例子裡面,因為我在ProductGroup下定義了材料、品牌、aggregateRating和offers等屬性,已經省去了3</a>0-40行程式碼左右,大約減少了20-25%整體回標籤數量。<br/><br/>而且那已經是通過引用標識符來壓縮標記不少了。若沒有利用引用而完全展開書寫——很容易就會增加100-150行額外回標籤數量。最後,我要提及每件商品仍然具備其自己Offer(報價)回樝籤部分置於ProductGroup.offers.Offer下面。<br/><br/> ```json { ′@context′: ′https://schema.org′, ′@type′: ′ProductGroup′, ′productGroupID′: ′abc123</a>′, ... } ``` “真是个好例子啊Jarno — 才怪!你应该在发布前测试一下你东西, 它产生错误和警告并且产品一个属性也没继承!”没错, 我清楚这个事实. 不过这并非因为缺乏技能或意识去恰当执行. 对于此类支持虽然即将来临, 现时却还未出现. 还反映在目前各种验证器/测试工具</a>对此类标记反应如何</a>。

在Google確信已經準備(足夠)就緒前,我們不會見到ProductGroup

鑒於標記組合的可能性數不勝數,加上這些標記可以表達的順序和所有可能發生的錯誤方式,必須從多個角度審視並進行測試,然後才能對外公布。在此過程中,細心謹慎至關重要,因為一旦處理不當,對出版商和消費者而言都可能造成極其嚴重的後果。在schema.org還有許多微小與重大的細節等待探討,但目前這些任務就交給了參與此事宜的谷歌工程師(及其同事)。<br/><br/>他們需要時間來釐清如何</a>讓這一切在他們系統內運作起來,在一開始會受到哪些限制,接著是真正實現功能並撰寫正確文檔以便我們按照他們期望的方式學習</a>使用。這也意味著我的標記範例絕不代表最終將採用的方法——無論是我書寫的順序、所包含的信息還是繼承將作用於多少屬性。我的範例基於我們在schema.org上進行討論時生成的想法,旨在幫助你開始自己的調查研究。<br/><br/>