SHMLANG Editorial Team

This article separates three things an editor often collapses into one: the anchor’s href destination, the browser behavior the download attribute requests, and what a reader can actually see before committing. It explains the documented same-origin restriction that silently turns a download link back into normal navigation, why the download attribute does not remove the href that Google needs to crawl a link, and how to write anchor text that tells the reader a download is coming. It then gives a reader-task rule for choosing a readable destination page instead, and closes by separating the download attribute from ranking, indexing, and paid-link qualification. No ranking, indexing, or citation outcome is promised. The link decision hiding behind the download attribute When an editor adds a download attribute to an anchor, it can feel like a small formatting choice. It is actually a decision about what the reader gets: a page they can read, or a file the browser handles on their behalf. The two outcomes are produced by different mechanisms, and mixing them up is what makes the choice feel arbitrary. Start with what the anchor element itself does. The <a> HTML element, with its href attribute, creates a hyperlink to web pages, files, email addresses, locations in the same page, or anything else a URL can address . The href is the destination. It is the part that points somewhere, and it is the part that exists whether or not a download attribute is present. The download attribute does not change that destination. It causes the browser to treat the linked URL as a download . The URL is the same URL. What changes is the browser’s handling of it, and therefore what the reader experiences after the click. That reader experience is not fully predictable from the markup alone. How browsers treat downloads varies by browser, user settings, and other factors. The user may be prompted before a download starts, or the file may be saved automatically, or it may open automatically, either in an external application or in the browser itself . A readable destination page, by contrast, is a navigation: the reader lands on a document with visible context and can scan it before deciding anything. So the real question is not which attribute is better. It is whether the reader’s task at this point is to read and evaluate, or to obtain a file. Keep that question in view, because the technical boundary in the next section decides whether the download option is even available for the link you are placing. MDN reference What the download attribute actually does and where it stops working The download attribute is a request to the browser, and the browser is allowed to decline it. The documented boundary is origin-based, and it is the single most common reason an editor’s download link behaves like an ordinary link. The attribute only works for same-origin URLs, same-origin blob:, and data: schemes. For other URLs, the download attribute is ignored and a normal navigation happens, although the target page may still use Content-Disposition to instruct a download . If you link to a file hosted on another domain, the attribute is inert. The reader navigates. If you want a download in that case, the control moves to the server hosting the file, through its Content-Disposition header. When the attribute is honored, it interacts with that same header. The download attribute, when honored, overrides the Content-Disposition: inline behavior, but the filename parameter of Content-Disposition overrides the name in the download attribute . In practice this means the filename a reader ends up with may not be the one you typed into the markup, because the server can still win that argument. Even when everything lines up, the outcome is not a single defined behavior. As noted above, the browser may prompt, save automatically, or open the file in an application or in the browser itself, depending on browser and user settings. That variability is a property of the download path, not a misconfiguration you can eliminate from the HTML. The practical boundary list for an editor is short: same-origin URL, same-origin blob:, or data: scheme, and the attribute can take effect; anything else, and you are relying on the destination server’s headers, not on your markup. Check which case you are in before you write anchor text that promises a download. Crawlability and anchor text: what survives when the link downloads A download link is still a link, provided the markup is the kind Google can read. Google states that it can only crawl your link if it’s an <a> HTML element (also known as anchor element) with an href attribute , and that most links in other formats will not be parsed and extracted by its crawlers. The download attribute does not remove the href, so the anchor keeps the structure that crawlability depends on. That is a statement about how links are read, not a promise about what happens to the file afterward. Google describes links as a signal when determining the relevancy of pages and to find new pages to crawl . Whether a particular downloadable file is indexed, and how it is treated, is not established by the download attribute itself. The labeling decision is where download links most often go wrong. Content within each <a> should indicate the link’s destination , and MDN adds a specific instruction for this case: Links that open in a new tab/window via target="_blank", or links that point to a download file should indicate what will happen when the link is followed . A reader who expects a page and gets a file has been misled by the anchor text, not by the attribute. Google’s definition of anchor text is the same one that applies here: Anchor text (also known as link text) is the visible text of a link. This text tells people and Google something about the page you’re linking to . And the quality bar is stated plainly: Good anchor text is descriptive, reasonably concise, and relevant to the page that it’s on and to the page it links to . For a download link, that means naming the artifact and signaling the behavior, rather than writing a generic phrase that could point anywhere. Source reference Related reading: Google Backlinks Using an Image Link and Its Alt Anchor Text Choosing a readable destination when the reader needs context A readable destination page gives the reader something a download cannot: visible context, surrounding explanation, and the ability to scan before committing. The download path removes the reader from the page they were on and hands the URL to the browser, which may open an external application or save a file. If the reader’s task is to evaluate, compare, or understand, the readable page is the surface that supports it. Google’s guidance on external links supports the readable-destination choice for a different reason. Linking to other sites isn’t something to be scared of; in fact, using external links can help establish trustworthiness (for example, citing your sources) . A citation works when the reader can see what is being cited. A file that downloads silently does not show the reader the source in context. Hypothetical illustration only; not a real client, test, or observed outcome. Picture a supplier page that mentions a pump’s operating limits. One version links to a specification page on the manufacturer’s site, where the reader can see the table, the surrounding notes, and the revision date. The other links to a downloadable datasheet. The reader who needs to check one number is served by the readable page; the reader who needs to attach a document to a procurement file is served by the download. The link decision follows the reader’s task, not the file’s existence. A workable rule: if the reader’s next action is to read, compare, or verify, link to the readable destination. If the reader’s next action is to obtain and keep a file, a download link is the honest choice, and the anchor text should say so. When both tasks exist, the readable page can carry the download as a secondary, clearly labeled link rather than forcing every reader through the browser’s download handling. Related reading: Google SEO for PDF Product Datasheets and HTML Product Pages: Duplicate, Distinct Task, or Canonical? What the download attribute does not do: ranking, indexing, and paid-link boundaries The download attribute is a browser-behavior instruction. It does not improve ranking, and it does not guarantee that a file is indexed. Google’s statement that links are used as a signal for relevancy and discovery describes how links are read in general; it does not establish that a download link produces either outcome for a specific file. Treat any claim that a download attribute boosts ranking or forces indexing as unsupported. The anchor text around the link is where a real risk sits. Google advises writing anchor text as naturally as possible and resisting the urge to cram every related keyword, because keyword stuffing is a violation of our spam policies. A download link does not exempt the editor from that boundary; if anything, the temptation to stuff a file name with terms is higher because the visible text is short. Paid-link qualification is a separate question from the download-versus-readable choice, and it should not be folded into it. Google states that if you were paid in some way for the link, you should qualify these links with sponsored or nofollow. That rule applies to the link transaction, not to whether the destination is a file or a page. Choosing a readable destination does not make a paid placement organic, and choosing a download does not make an unpaid link sponsored. What remains unknown is how any specific site’s download links are treated in indexing, and which file types Google indexes from them. The decision this article supports is narrower and defensible: pick the destination that matches the reader’s task, keep the anchor crawlable and descriptive, and keep paid-link qualification where it belongs.

图片型外链没有可见文字时，alt 就是这条链接的锚文本。本文按 Google 官方链接文档，先确认外层是否为可抓取的 <a href> 锚点，再给出 alt 的写法方向：描述目标页面或点击结果，而不是罗列关键词；同时说明空 alt 的边界、长度判断依据、周边文字与脚本插入的核验方式，并划清它与付费链接属性、图片收录、图片版权三类问题的界限。 先确认这条外链是不是“图片链接” 看到一条只有图片、没有可见文字的外链，很多人的第一反应是去改图片的 alt。但在动手之前，有一个更靠前的问题需要先回答：这条链接在当前形态下，到底会不会被当作链接处理。如果外层形态不成立，alt 写什么都不会进入“作为锚文本被使用”的讨论。 Google 官方链接最佳实践文档给出的前提是：Google 通常只能抓取以带 href 属性的 <a> 元素形式存在的链接，其他格式的链接大多不会被解析和提取；对于没有 href 属性的 <a> 元素，或者靠脚本事件充当链接的其他标签，Google 也无法可靠地提取其中的 URL（ 来源： Google 链接最佳实践 ）。 把这条前提落到实际场景，可以分成三种情况分别判断。第一种，图片本身可点击，但外层不是标准的 <a href>，例如用 span 加脚本事件、或者用前端路由属性代替 href。这类写法在浏览器里看起来能跳转，但它不在“可抓取链接”的范围内，alt 也就不承担锚文本角色。第二种，图片被 <a href> 包裹，href 指向一个真实可解析的地址。这是本文讨论的对象。第三种，图片只是装饰，外层没有任何链接。这种情况下 alt 服务于图片本身的可访问性描述，与链接语义无关。 判断顺序建议固定为三步，不要跳步。先看外层元素是不是 <a>；再看 href 是否指向一个真实可解析的地址，而不是 javascript: 之类的伪地址；最后才看 alt 写了什么。前两步不成立时，第三步的讨论没有意义。 这里有一条证据边界需要说明：本文无法判断某条具体外链在第三方页面上的实际呈现——对方是否加了 rel 属性、图片是否被懒加载或裁剪，这些都需要读者在自己的页面上核对，不能从本文推断。 Source reference 相关阅读: Google外链建设流程教程：从可链接资产到真实推荐链接 图片链接的 alt 就是它的锚文本 确认了外层是可抓取的锚点之后，接下来要确立的是这条链接的语义来源。很多人对 alt 的认知停留在“给屏幕阅读器用的图片描述”，但在图片作为链接的场景下，alt 还承担了另一个角色。 Google 官方文档对此有直接表述：对于作为链接的图片，Google 使用 img 元素的 alt 属性作为锚文本，因此应当为图片添加描述性的 alt 文本（ 来源： Google 链接最佳实践 ）。 要理解这句话的分量，需要先知道锚文本在官方定义里是什么。官方把锚文本（也称链接文字）定义为链接的可见文本，这段文字告诉人和 Google 目标页面是关于什么的，并且应当放在 Google 可抓取的 <a> 元素之间（ 来源： Google 链接最佳实践 ）。 把这两条放在一起，结论就清楚了：当图片是链接的唯一内容时，页面上没有任何可见文字，alt 实际上顶替了“可见文字锚文本”的位置。它同时面向两类读者——使用辅助技术的访客需要它知道这个链接通向哪里，普通访客的点击预期也由它设定；同时它也是搜索系统读取这条链接含义的入口。 由此可以推出空 alt 的边界。官方把“alt 为空且链接文字为空”的图片链接列为不良做法，给出的反面示例是 <a href="/add-to-cart.html"><img src="enchiladas-in-shopping-cart.jpg" alt=""/></a>（ 来源： Google 链接最佳实践 ）。也就是说，当图片是链接的唯一内容时，留空等于这条链接没有可用的锚文本。 还有一个容易被当成替代方案的写法需要澄清：官方说明，作为回退，如果 <a> 元素出于某种原因为空，Google 可以使用 title 属性作为锚文本（ 来源： Google 链接最佳实践 ）。注意这里的措辞是“回退”，它描述的是锚点为空时的一种补救可能，而不是推荐做法。把 title 当作首选、把 alt 留空，是把回退机制当成了主路径。 alt 写什么：描述目标页，而不是罗列关键词 确立了 alt 是锚文本之后，最核心的问题就是写什么。官方给出的正面示例提供了一个可以直接抽象的判断方向： <a href="/add-to-cart.html"><img src="enchiladas-in-shopping-cart.jpg" alt=" add enchiladas to your cart "/></a> ，即 alt 描述点击后会发生什么。 这个示例值得逐字读。alt 写的是“add enchiladas to your cart”，描述的是点击之后会发生什么，而不是“一张购物车里的墨西哥卷饼照片”。图片文件名里确实有 enchiladas-in-shopping-cart 这样的描述，但官方没有把文件名搬进 alt，而是写了动作与结果。这就是“描述图片内容”和“描述链接目的地”的分野：前者回答“这张图长什么样”，后者回答“点下去会到哪里、会发生什么”。图片链接的 alt 属于后者。 官方对好锚文本的定义可以拿来当写作标准：描述性、适度简洁、与所在页面和所链接页面都相关，它为目标页面提供上下文，并为读者设定预期。 把这条标准套到图片链接上，“与所在页面相关”意味着 alt 要能接上图片周围那段正文在讲什么，“与所链接页面相关”意味着 alt 要指向目标页的主题。 官方还给了一个很实用的自检方法：把锚文本单独拿出来读，看它脱离上下文是否足够具体、能让人明白目标页面讲什么；如果读不出，就需要更具描述性的锚文本。 对图片链接来说，这个自检尤其必要，因为页面上没有其他可见文字可以补救。 关键词堆砌的边界也在同一份文档里。官方要求锚文本尽量自然书写，不要把所有与目标页相关的关键词都塞进去，并明确指出关键词堆砌违反垃圾内容政策；官方建议自问：读者是否需要这些关键词才能理解下一页。 以下为假设/虚构演示场景，仅用于说明写法方向，不代表任何真实站点、真实客户或实测结果。 假设合作方页面上放了一张品牌 logo，外层是 <a href> 指向你的首页。此时 alt 描述的是“去哪个站点、去哪个页面”，而不是把品牌词、行业词、产品词串成一长串。 以下为假设/虚构演示场景，仅用于说明写法方向，不代表任何真实站点、真实客户或实测结果。 假设同一页面上还有一张产品图，外层指向某个具体产品页，那么 alt 的方向是让读者知道点进去会看到哪一类产品，而不是把该品类的所有关键词列一遍。 以下为假设/虚构演示场景，仅用于说明写法方向，不代表任何真实站点、真实客户或实测结果。 假设是一张按钮图，外层指向询盘表单页，alt 描述的是点击后进入的动作或页面，而不是按钮的视觉样式。 这些情况的共同点是：alt 回答“点下去到哪里”，而不是“这张图里有什么”。 alt 写多长、周边文字怎么配合 长度是执行时最容易被追问的问题，但官方文档里没有给出任何字符数阈值。官方对好锚文本的表述是“描述性、适度简洁”，并给出过长锚文本的反面示例与更简洁的改写（ 来源： Google 链接最佳实践 ）。因此可用的判断依据不是字数，而是上一节那条自检：把 alt 单独拿出来读，是否足够具体、又不显得冗长。任何具体的字符数上限都是编造的。 周边文字的作用同样有官方依据。官方说明链接前后的文字也构成上下文，应当关注整句，并且不要把多个链接紧挨着串联，否则读者难以区分链接，每个链接也失去周围文本（ 来源： Google 链接最佳实践 ）。 把这条落到图片型外链上，alt 与周边正文是互补关系：alt 负责说明目的地，正文负责说明为什么在这里提到它。如果图片周围只有一句“合作伙伴”之类的标签，读者即使读了 alt 也不知道这个链接和当前内容有什么关系。反过来，如果正文已经交代了背景，alt 就不需要重复一遍背景，只需要把目的地说清楚。 还有一种情况需要单独核验：如果 alt 是由脚本动态插入的，官方建议使用 URL Inspection Tool 确认它出现在渲染后的 HTML 中（ 来源： Google 链接最佳实践 ）。这条针对的是“写对了但没生效”的情形——源码里看不到，渲染后才出现，需要工具确认实际结果。 哪些情况不属于本文的 alt 写法问题 alt 写法只是图片型外链的一个环节，把它当成万能解法会在错误的层级上反复修改。以下几类问题需要分开处理。 第一类是链接属性。官方说明，如果链接以某种方式付费获得，应使用 sponsored 或 nofollow 限定；如果用户可以在站点上插入链接，应加 ugc 或 nofollow（ 来源： Google 链接最佳实践 ）。这属于“这条链接的关系该怎么声明”，与“alt 写什么”是两个独立决策。alt 写得再准确，也不会改变一条付费链接应当被限定的判断。 第二类是图片能否被图片搜索收录、图片格式与站点地图。这属于图片发现与索引层面的问题，判断对象是图片 URL 是否可被抓取、来源是否可被发现、落地页是否可索引，与“alt 作为锚文本”不是同一个判断。站内《Google图片SEO：发现、索引、语义与性能验收》处理的是这条线，本文不重复。 第三类是图片版权与署名。这属于授权层面，与 alt 的语义无关。站内《网站图片资产治理：版权、格式、Alt与归档》处理的是图片资产的版权、格式与归档字段设计，本文不重复。 最后需要明确的是：本文不承诺任何排名、收录或流量结果。alt 写法的作用是让这条链接的语义更清晰，让读者和搜索系统更容易理解它指向什么，这不是效果保证。 相关阅读: 展会参展商介绍页的Google外链如何核验：从参展商身份到付费链接属性 相关阅读: Google图片SEO：发现、索引、语义与性能验收

An image-only hyperlink has no visible text, so the alt attribute of the img element becomes the link’s anchor text in Google’s documented handling. This article explains what that means for the reader’s decision: how to write alt text that describes the destination rather than the picture, what happens when alt is empty, why the surrounding sentence still carries context, how to confirm the value survives rendering, and where the boundary sits between descriptive semantics and any ranking or endorsement outcome. What an image-only link actually says about its destination When a link contains only a logo, thumbnail, or icon and no visible words, the reader’s question is not whether the link works but what it communicates. Google’s documentation defines anchor text as the visible text of a link and states that this text tells people and Google something about the page being linked to. For an image-only link, that visible text is absent, so the documented mechanism shifts to the image itself: for images as links, Google uses the alt attribute of the img element as anchor text. This is a semantics question, not a crawlability question, but the two are linked. The alt attribute only functions as anchor text if the surrounding markup is a link Google can actually parse. Google states that it can generally only crawl a link if it is an <a> HTML element with an href attribute, and that most links in other formats will not be parsed and extracted by its crawlers. So the reader’s decision has a prerequisite: confirm the image sits inside a real anchor element before worrying about what the alt text says. Hypothetical illustration only; not a real client, test, or observed outcome. Consider a hypothetical: a supplier’s homepage carries a logo link to its product catalog. In one version the alt attribute reads "logo"; in the other it reads "Acme industrial pumps catalog." The first tells a reader and a search engine almost nothing about where the link goes; the second names the destination. This is a hypothetical illustration, not a measured test or a client example. Source reference Related reading: Google Image SEO: Discovery, Indexing, Context, and Performance Checks Writing alt text that describes the destination, not the picture Once the reader accepts that alt text is the anchor text for an image-only link, the writing decision becomes concrete. Google’s guidance is that good anchor text is descriptive, reasonably concise, and relevant to the page it is on and to the page it links to, and that it provides context and sets reader expectations. That framing points away from describing the picture and toward describing the destination. An alt value that names the visual subject — "blue pump photo" — does not tell anyone what the link leads to. An alt value that names the destination or the action — "add enchiladas to your cart" — does. Google’s own good example for an image link uses an anchor wrapping an img whose alt attribute reads "add enchiladas to your cart," which describes the action the link performs rather than the image content. The temptation with an image-only link is to compensate for the missing visible text by loading the alt attribute with every related term. Google advises writing as naturally as possible and resisting the urge to cram every related keyword, noting that keyword stuffing is a violation of its spam policies, and suggests asking whether the reader actually needs those keywords to understand the next page. Hypothetical illustration only; not a real client, test, or observed outcome. A hypothetical pair makes the difference visible. One version of a product-thumbnail link carries an alt string that stacks brand, category, model, and several synonyms; the other carries a short phrase naming the product family and the action of viewing it. The second is the one a reader could understand without seeing the image. This is a hypothetical illustration, not a measured comparison. When alt text is empty or missing The failure mode for an image-only link is an empty alt attribute. Google’s documentation shows a bad example in which an anchor wraps an img whose alt attribute is empty, and labels it as having both empty alt text and empty link text. In that state the link has no usable anchor text from either the visible layer or the image layer, which is why the documentation treats it as the negative case rather than a neutral one. There is a documented fallback, but it is narrower than it first appears. Google states that as a fallback it can use the title attribute as anchor text if the <a> element is for some reason empty. That fallback applies to an empty anchor element; for an image link, the primary documented mechanism remains the img alt attribute. Hypothetical illustration only; not a real client, test, or observed outcome. Consider a hypothetical: an icon-only cart button. In one version the alt attribute is empty and the anchor carries no other text; in the other the alt attribute reads "add to cart." The first leaves the link with nothing to communicate; the second names the action. This is a hypothetical illustration, not a measured test. Whether a given site’s alt text was ever reviewed by a human is not something an outside reader can determine from the markup alone. Treat that as a conditional check: if you cannot find a record of who wrote or approved the alt value, verify it yourself against the destination rather than assuming it was reviewed. The sentence around the image link still matters Alt text is not the only context signal an image-only link carries. Google states that the words before and after links matter, that attention should be paid to the sentence as a whole, and that links should not be chained next to each other because it is harder for readers to distinguish between them and surrounding text is lost for each link. This is a decision the reader can act on without touching any markup. A row of icon links with no surrounding prose gives each link only its alt attribute to work with. The same icons spaced apart and introduced by descriptive sentences give each link a sentence to sit inside, which is the arrangement the documentation favors. Hypothetical illustration only; not a real client, test, or observed outcome. Consider a hypothetical: a footer row of social and product icons placed directly adjacent to one another, compared with the same icons separated by short descriptive sentences. The second arrangement gives a reader a reason to click each one. This is a hypothetical illustration, not a measured comparison. Checking what the crawler actually receives What the editor writes and what the crawler receives are not always the same thing, particularly when a script assembles the link. Google recommends using the URL Inspection Tool to make sure JavaScript-inserted anchor text is present in the rendered HTML. The same crawlability rule from earlier applies here: the link must be an <a> element with an href attribute for Google to crawl it, and script-only handlers are not a reliable substitute. A practical verification sequence for one representative image link: Open the page source and confirm the image sits inside an <a> element with an href attribute. Read the alt attribute in the source and check that it names the destination or action. If a script inserts the link or its text, use the URL Inspection Tool to confirm the value appears in the rendered HTML. Compare the rendered value against what you intended to write, and fix the source if they differ. This sequence confirms what the crawler receives. It does not confirm that the link will be indexed, ranked, or cited, and no such outcome is promised here. What this does not do: no ranking or endorsement guarantee It is worth being precise about what descriptive alt text on an image link achieves. Google uses links as a signal when determining the relevancy of pages and to find new pages to crawl, and anchor text tells people and Google something about the page being linked to. That is a description of a signal and a context mechanism. The documentation does not promise ranking outcomes from anchor text or alt text, and no ranking data was supplied for this article. There is also a qualification rule that applies regardless of whether the link is text or image. Google states that if you were paid in some way for a link, you should qualify it with sponsored or nofollow, and that if users can insert links on your site, you should add ugc or nofollow. Hypothetical illustration only; not a real client, test, or observed outcome. Consider a hypothetical: a paid logo placement that visually resembles an editorial image link. The descriptive alt text does not change what the link is; the paid-link attribute is what discloses the transaction. This is a hypothetical illustration, not a real placement or client example. The reader’s decision, then, is bounded: write alt text that describes the destination, place the link in a sentence that gives it context, verify what the crawler receives, and qualify the link if it was paid for. None of those steps is a promise of ranking or endorsement. Related reading: How to Evaluate Google Backlink Services: A Buyer’s Guide to Sources, Screening, Evidence, and Risk

A recent ‘last updated’ stamp on a page does not tell you whether a commercial offer is still valid. This article separates the offer’s own declared validity interval from the document’s edit date, explains the documented validFrom and validThrough vocabulary in its supported Offer scope, and gives a concrete procedure for deciding whether an offer is currently live — plus what to do when the term is missing or appears expired. The offer’s own clock, not the page’s You land on a page that describes a discount, an incentive, or a promotional term. Near the top there is a date — ‘last updated’ or ‘last modified’ — and it is recent. It is tempting to read that freshness as proof the offer is still live. It is not. A page’s update date is a document-editing signal: it records when someone changed the page. It does not, by itself, state when a commercial offer starts or ends. An offer’s validity is expressed through its own declared start and end terms. Schema.org defines validFrom as the date when the item becomes valid, and validThrough as the date after when the item is not valid, giving the end of an offer as one example. Those two terms describe the offer’s own clock. The page’s edit date describes the document’s clock. They are different clocks, and only one of them governs whether the offer is live. So the reader’s decision is this: before treating a fresh-looking page as proof that an offer is live, find the offer’s declared interval and check it. If the page shows a recent edit date but no declared start or end for the offer, you do not yet have the information you need to conclude the offer is valid. Source reference Source reference What validFrom and validThrough actually say The vocabulary you are looking for is documented on Schema.org. The validFrom property page states that it is the date when the item becomes valid. The validThrough property page states that it is the date after when the item is not valid, and it explicitly gives the end of an offer as an example. Read together, they describe a start and an end: the moment the item becomes valid, and the moment after which it is not. Both properties are listed as used on the Offer type. That is the supported offer scope: when you are reading a commercial offer, these are the terms that describe its declared interval. Both properties also expect values of type Date or DateTime, so the declared term may appear as a calendar date or as a date with a time. One more detail is worth knowing because it tells you these terms are not a Schema.org invention. Each has an equivalent property in another vocabulary: validFrom is equivalent to cmns-dt:hasStartDate, and validThrough is equivalent to cmns-dt:hasEndDate. The start/end framing is the intended reading. Reading an offer’s interval against today’s date With the vocabulary in hand, the decision procedure is short. Find the offer’s declared start and end. Compare the current date to both. If today is before the declared start, the offer is not yet valid. If today is after the declared end, the item is not valid. Only when today falls inside the declared interval — at or after the start and at or before the end — is the offer within its own stated window. This is a hypothetical illustration, not a real client case or observed test. Here is a hypothetical example to make the failure mode concrete. Suppose a page carries a ‘last updated’ stamp from this week and advertises a promotional term whose declared end date has already passed. The page is fresh; the offer is not. The correct conclusion is that the offer is outside its declared interval, and the recent edit date does not change that. This is a hypothetical illustration, not a real client case or observed test. Now the other failure mode. Suppose a page describes an offer with a declared start but no declared end. It is tempting to read ‘no end date’ as ‘open-ended offer.’ That is not what the absence of a term means. An absent end term is simply absent information; it is not a statement that the offer continues indefinitely. The same logic applies to an absent start term. Missing is missing, and it should send you to the seller rather than to a conclusion. When the term is missing or expired: confirm with the seller If the offer’s declared term is absent, or if it appears to have passed, the next action is to confirm the current terms with the seller. Do not infer renewal from a recent page update. The page’s edit date is not a substitute for the seller’s confirmation, because the edit date tells you about the document, not about the offer’s declared interval. A caution about what you can and cannot conclude from the page alone. Whether a specific seller reviews or renews its offer wording is unknown from the page. You cannot tell from a recent edit date whether the seller re-checked the offer, extended it, or simply fixed a typo. Treat this as a buyer check — ask the seller — rather than as an assumption in either direction. The same applies to the opposite assumption: a stale-looking page does not prove the offer has lapsed if the declared interval is still open. Why this matters for GEO and structured offer data For a content or GEO team, the practical reason to care is accuracy. The validFrom property page reports usage across 100K–1M domains, and the validThrough property page reports usage across 1M–10M domains, both based on monthly aggregations from Google’s web index (Google – August 2026). These are widely used terms, which means readers and systems have a reasonable expectation that a declared interval means what it says. Keeping an offer’s declared interval accurate is a content-accuracy concern. It is not a guarantee of AI citation, ranking, or indexing. No formatting choice, structured-data field, or page edit can promise that an AI system will surface your offer or that a search engine will rank it. What you can control is whether the declared interval on the page matches reality — and that is the part the reader is actually relying on. If you are building the governance side of this — deciding when evidence should be updated, downgraded, or withdrawn — the GEO evidence expiry workflow covers that decision. And if the problem is propagating a corrected fact across pages, locales, and structured data, the GEO source update governance guide addresses the notification chain. Both are adjacent to this topic but answer different questions: this article is about reading an offer’s own declared interval, not about managing an evidence library. Related reading: GEO Evidence Expiry: Update, Downgrade, or Withdraw Related reading: GEO Source Update Governance when Facts Change

A contact page that loads at any hour is a document, not a staffed channel. This note separates the two using the documented meanings of ContactPoint, hoursAvailable and OpeningHoursSpecification, then gives a reading order for weekly schedules, overnight ranges and date-specific exceptions, and a buyer check that ends with a direct question to the provider rather than an assumption about staffing. The page that never closes is not the channel that answers A contact page that loads at 3 a.m. proves one thing: the web server answered. It does not prove that anyone is at a desk, watching a shared inbox, or able to pick up the phone. Those are two different objects, and the vocabulary treats them as two different objects. schema.org defines a ContactPoint as "a contact point—for example, a Customer Complaints department" ( https://schema.org/ContactPoint ). Separately, it defines hoursAvailable as "the hours during which this service or contact is available" ( https://schema.org/hoursAvailable ). One term names the channel; the other names the window in which that channel is available. Neither term describes the website. That is the separation rule to apply before you trust a phone number or a form. Page reachability is a hosting fact. Channel staffing is an operating fact. A page that never closes tells you nothing about the second, and a page that does state hours is making a claim about the channel, not about the site. Source reference Source reference Which field actually carries a channel’s hours If a page does state hours, the field to look for is hoursAvailable, and its scope is narrow. It is defined as the hours during which this service or contact is available, and its expected value type is OpeningHoursSpecification ( https://schema.org/hoursAvailable ). It is used on ContactPoint, LocationFeatureSpecification and Service ( https://schema.org/hoursAvailable ). Read that list of types carefully, because it is the whole point. The field attaches to a contact point, a location feature, or a service. It does not attach to the website as a whole. A site-wide banner reading "open 24/7" is not the same statement as hoursAvailable on a specific contact point, and the two can coexist while meaning different things. The official example shows the shape this takes in practice: hoursAvailable attached to a LocationFeatureSpecification, with an OpeningHoursSpecification value carrying dayOfWeek, opens and closes ( https://schema.org/hoursAvailable ). The hours belong to the feature being described, not to the page that describes it. The relationship runs both ways. OpeningHoursSpecification lists hoursAvailable among the properties that may take it as a value, on ContactPoint, LocationFeatureSpecification or Service ( https://schema.org/OpeningHoursSpecification ). So when you find a schedule block, the question to ask is which contact point or service it is bound to. Source reference Reading a weekly schedule and its exceptions OpeningHoursSpecification is "a structured value providing information about the opening hours of a place or a certain service inside a place" ( https://schema.org/OpeningHoursSpecification ). Its properties include closes, dayOfWeek, opens, validFrom and validThrough ( https://schema.org/OpeningHoursSpecification ). A useful reading order follows the properties rather than the visual layout. Start with dayOfWeek, because it tells you which days the block covers. Then read opens and closes as the daily window. Two rules govern the edges. The place is open if the opens property is specified, and closed otherwise ( https://schema.org/OpeningHoursSpecification ). And if the value for closes is less than the value for opens, the hour range is assumed to span over the next day ( https://schema.org/OpeningHoursSpecification ). That second rule is the one readers miss: a block that opens late and closes in the early morning is not a typo, it is an overnight window. Then check whether the block is general or dated. validFrom and validThrough mark the period in which the entry applies, and specialOpeningHoursSpecification is used to explicitly override general opening hours brought in scope by openingHoursSpecification or openingHours ( https://schema.org/OpeningHoursSpecification ). The official example shows the pattern: a general openingHours line for the normal week, plus dated OpeningHoursSpecification entries using validFrom and validThrough for date-specific exceptions ( https://schema.org/OpeningHoursSpecification ). Hypothetical illustration, not a real provider or measured outcome. Hypothetical schedule, not a real provider: a support line carries a general weekly block, and a separate dated entry narrows the window on a public holiday. A reader who stops at the general block will assume the holiday follows the normal week. The dated entry is the one that answers the question they actually have. Related reading: Multilingual Product Availability on Export Websites: Keeping Two Language Pages Consistent Matching hours to the right channel A schedule is only useful once you know which channel it belongs to. contactType is the property that specifies the kind of contact point, and schema.org notes that a person or organization can have different contact points for different purposes, giving a sales contact point and a PR contact point as examples ( https://schema.org/ContactPoint ). Different purposes can carry different hours. Two more properties describe the channel without describing its schedule. contactOption is "an option available on this contact point (e.g. a toll-free number or support for hearing-impaired callers)" ( https://schema.org/ContactPoint ). availableLanguage is "a language someone may use with or at the item, service or place," with IETF BCP 47 codes recommended ( https://schema.org/ContactPoint ). Neither one is a statement about when someone is present. The official example 3 illustrates the shape of a multi-channel contact list: several contact numbers for one company, including US toll-free numbers, a hearing-impaired number, and several contact categories ( https://schema.org/ContactPoint ). When a page looks like that, hours read as attached to a specific contact point rather than to the company as a whole. Hypothetical illustration, not a real provider or measured outcome. Hypothetical contact list, not a real provider: a page shows a sales line, a support line and a general inbox. The support line carries a stated window; the sales line and the inbox carry none. The correct reading is that the support channel has stated hours while the other channels have unstated hours, not that the company is reachable whenever the support line is. Related reading: Professional Services Website Trust: People, Process, Evidence What the vocabulary does not tell you The vocabulary defines fields, not staffing. Nothing in hoursAvailable, OpeningHoursSpecification or ContactPoint states a timezone, a response time, or how many people are on duty. A well-formed schedule can be complete as markup and still leave the reader’s actual question unanswered. The neighbouring properties do not close that gap either. areaServed is "the geographic area where a service or offered item is provided," and it supersedes serviceArea ( https://schema.org/ContactPoint ). availableLanguage describes languages ( https://schema.org/ContactPoint ). contactOption describes options such as toll-free or hearing-impaired support ( https://schema.org/ContactPoint ). Coverage, language and channel options are all useful facts, and none of them is a staffing guarantee. The official example 1 shows how much detail a page can carry without settling the question: it describes a GovernmentService with a Veterans Crisis Line, including phone contact line hours of operation, language and other details ( https://schema.org/ContactPoint ). That is a rich, well-specified contact description. It still does not tell a reader whether a human will answer at a particular moment. So the unknowns to carry forward are concrete: the timezone the stated hours refer to, the expected response time for the channel you intend to use, and whether the channel is staffed by a person or handled asynchronously. Those values have to come from the provider. They are not in the markup, and no amount of careful reading will extract them. A practical check before you rely on a contact channel Run these steps in order, and stop at the first one that fails. Read the page for a channel-specific hours statement, and check whether it is attached to the contact point you intend to use. A schedule bound to a different channel does not answer your question. Check whether the stated hours include a timezone or a reference to your own location. If they do not, treat the timezone as unstated rather than assuming it matches yours. Check whether exceptions are stated for the date you care about, using the validFrom and validThrough properties and the specialOpeningHoursSpecification override ( https://schema.org/OpeningHoursSpecification ). A general weekly block is not a statement about a holiday. If the page does not state channel-specific hours, ask the provider directly for the hours, the timezone those hours refer to, and the expected response time of that channel. Do not treat the presence of a form, a phone number, or a page that loads at any hour as evidence that the channel is staffed. Those are availability facts about the page, not about the people behind it. For the adjacent question of how a provider’s delivery model changes what you are buying, see GEO Service Area Content: Reading Remote and Onsite Delivery Boundaries . Related reading: GEO Service Area Content: Reading Remote and Onsite Delivery Boundaries

本文面向正在评估跨境服务的中文买家与内容编辑，回答一个具体决策：看到英文服务页或英文联系方式时，如何判断它是否代表该服务渠道真的支持英文沟通。文章依据 schema.org 对 availableLanguage 与 ContactPoint 的官方定义，把“页面/内容语言”与“服务渠道可用语言”拆成两个独立判断对象，说明 availableLanguage 在其定义范围内描述什么、不描述什么，并给出按渠道逐项核对与条件化表述的可执行方法。文中所有语言能力场景均为标注的假设示例，不构成对任何供应商实际语言能力的断言。 英文页面不等于英文服务：先分清两个判断对象 买家看到一个英文服务页，最自然的推断是“对方能用英文沟通”。这个推断之所以经常出错，是因为它把两个不同的判断对象合并成了一个：页面文本使用什么语言，以及服务渠道实际能承接什么语言。前者是你在页面上直接看到的事实，后者是对方在电话、邮件或客服环节实际具备的能力。两者可以一致，也可以完全不一致，而页面本身无法告诉你属于哪一种。 schema.org 对 availableLanguage 的定义是“某人可以在该条目、服务或场所使用或接触到的语言”，并要求使用 IETF BCP 47 标准的语言代码（来源： https://schema.org/availableLanguage ）。注意这个定义指向的是“在服务或场所可以使用或接触到的语言”，而不是“页面被写成了什么语言”。也就是说，官方词汇本身就承认这两件事是分开的：页面语言属于内容呈现，可用语言属于服务能力。 把这两件事分开之后，判断顺序就清楚了。第一步看页面：页面语言可以直接观察，不需要任何额外依据。第二步看渠道：服务渠道的语言能力需要渠道层面的依据，例如对方书面确认、实际回复语言，或渠道说明中明确写出的语言范围。缺少第二步依据时，正确的状态是“未确认”，而不是默认成立。 以下为假设示例，仅用于说明判断方法，不代表任何真实供应商的实际语言能力。 假设示例：某供应商的服务页为英文，页面内容完整、表述专业，但对接渠道只有中文客服，英文询价需要转交处理。这个示例仅用于说明“页面语言”与“渠道语言能力”可以分离，不代表任何真实供应商的情况。 本文不判断任何具体供应商的实际语言能力，也不推断某家服务商是否审校过其页面翻译。这些属于需要向对方书面确认的事项，而不是可以从页面语言推断出来的结论。 Source reference availableLanguage 描述的是什么：官方定义的边界 既然判断要落到渠道层面，就需要先弄清 availableLanguage 这个词汇本身能承载什么。官方定义是“某人可以在该条目、服务或场所使用或接触到的语言”，并要求使用 IETF BCP 47 标准的语言代码，另参见 inLanguage（来源： https://schema.org/availableLanguage ）。这个定义描述的是服务或场所层面的可用语言，而不是页面文本的语言。 取值类型方面，availableLanguage 期望的类型是 Language 或 Text（来源： https://schema.org/availableLanguage ）。这意味着它可以承载一个语言对象，也可以承载一段文本描述。类型本身不规定内容必须多具体，也不规定填写者必须提供什么证明。 适用类型方面，该属性可用于 ContactPoint、Course、LodgingBusiness、ServiceChannel、TouristAttraction 等类型（来源： https://schema.org/availableLanguage ）。这个适用范围说明它被设计成可以挂在多种实体上，包括联系点和服务渠道。 在 ContactPoint 上，availableLanguage 的说明同样是“某人可以在该条目、服务或场所使用或接触到的语言”，并要求使用 IETF BCP 47 语言代码（来源： https://schema.org/ContactPoint ）。两处定义一致，都指向服务层面的可用语言。 这里需要明确一条边界：官方定义只说明这个词汇描述什么，不规定任何具体组织是否真的具备该语言能力，也不构成对某供应商语言能力的证明。填写这个字段不会让服务真的支持某语言，不填写也不代表服务不支持。字段是词汇位置，不是能力证明。 Source reference 按渠道分别核对：电话、邮件、客服各有各的语言 词汇边界确定之后，下一个问题是核对单位。一个组织整体“支持某语言”，并不自动意味着它的每个联系渠道都支持该语言。schema.org 对 ContactPoint 的定义是“一个联系点——例如客户投诉部门”（来源： https://schema.org/ContactPoint ）。这个定义本身就暗示了联系点是按用途划分的，而不是一个笼统的整体。 contactType 属性进一步说明了这一点：一个人或组织可以针对不同目的拥有不同联系点，例如销售联系点、公关联系点等，该属性用于说明联系点的种类（来源： https://schema.org/ContactPoint ）。既然联系点按目的区分，语言能力也应当按联系点分别核对，而不是从整站语言推断。 每个联系点可以携带自己的字段。telephone 的类型为 Text，描述为电话号码（来源： https://schema.org/ContactPoint ）；email 的类型为 Text，描述为电子邮件地址（来源： https://schema.org/ContactPoint ）；hoursAvailable 表示该服务或联系点可用的时间段（来源： https://schema.org/ContactPoint ）；areaServed 表示服务或所提供项目的地理区域，并取代 serviceArea（来源： https://schema.org/ContactPoint ）。这些字段各自描述一个维度，语言能力是其中一个维度，不能由其他维度推出。 官方示例也支持按渠道核对的做法。在 ContactPoint 的示例中，一个组织可以列出多个 contactPoint，分别带有不同的 telephone、contactType、contactOption 与 areaServed（来源： https://schema.org/ContactPoint ）。另一个示例中，GovernmentService 的 availableChannel（ServiceChannel）单独带有 availableLanguage，其值为 Language 类型、name 为 Spanish、alternateName 为 es（来源： https://schema.org/ContactPoint ）。这说明语言能力可以挂在具体渠道上，而不是只能挂在组织整体上。 由此得到核对方法：把电话、邮件、在线客服等渠道分别列出，逐个确认该渠道能承接哪些语言。具体某供应商各渠道的实际语言能力，本文不掌握，需要向对方书面确认。 相关阅读: 远程与现场交付的服务范围怎么写：把所在地、覆盖地区与交付方式分开 联系前可以问什么：把不确定性降到可接受范围 把区分落到动作上，联系前可以做的事情并不多，但足以把误判概率降下来。以下动作是核对方法，不是对任何供应商能力的断言。 第一，向对方索取渠道层面的语言能力书面说明。既然 ContactPoint 允许按目的区分不同联系点（来源： https://schema.org/ContactPoint ），索取时也应当按渠道分别提问，而不是笼统地问“你们支持英文吗”。 第二，先通过低成本的书面渠道试探实际回复语言。email 是 ContactPoint 上的一个字段，类型为 Text，描述为电子邮件地址（来源： https://schema.org/ContactPoint ）。用邮件发起一次实际沟通，观察对方回复使用的语言，比从页面语言推断更接近实际能力。 第三，把“已确认”与“未确认”分开记录。ContactPoint 的定义是“一个联系点——例如客户投诉部门”（来源： https://schema.org/ContactPoint ），不同联系点可以有不同的实际安排。未确认的渠道不应写成结论，也不应因为其他渠道已确认就默认成立。 这些动作的价值在于把不确定性显式化。如果对方无法提供渠道层面的书面说明，这本身就是一个需要记录的信息，而不是一个可以用页面语言填补的空白。 写页面时怎么表述：条件化而不是承诺 买家侧的区分方法，反过来也适用于编辑侧。如果手上只有页面翻译，没有渠道语言能力的依据，页面文案就不应把页面语言写成服务承诺。 可依据的边界仍然是 availableLanguage 的定义：它描述的是“某人可以在该条目、服务或场所使用或接触到的语言”，并要求使用 IETF BCP 47 语言代码（来源： https://schema.org/availableLanguage ）。在 ContactPoint 上，该属性的说明一致（来源： https://schema.org/ContactPoint ）。既然定义指向服务层面的可用语言，页面表述就应当限定在可核验的渠道与语言上。 条件化写法的一个方向是：说明该渠道可用语言以书面确认为准，而不是直接写“我们支持多语言服务”。这样写不会让读者误以为页面语言等于服务承诺，也不会在对方实际能力与页面表述不一致时产生落差。 以下为假设示例，仅用于说明条件化表述的方向，不代表任何真实页面或供应商。 假设示例：某服务页原文写“我们提供多语言服务支持”。在缺少渠道语言能力依据时，可改写为“本页提供中文与英文内容；具体沟通渠道的可用语言，请以书面确认为准”。这个示例仅用于说明条件化表述的方向，不代表任何真实页面或供应商。 需要强调的是，这是编辑侧的表述方法，不是对任何供应商实际能力的断言。页面怎么写，不改变渠道实际支持什么语言；渠道实际支持什么语言，也不由页面表述决定。 相关阅读: GEO引用准备：事实、来源与页面证据如何连接