SEO editorial field guide
Use this guide to document an existing article’s own publication or meaningful-update history. It is not an instruction to change a date, alter markup, refresh a page cosmetically, or predict what any Search result will show.
Article dates often look harmless. A small line such as “Published June 8” or “Last updated October 3” can sit quietly below a title while readers focus on the body. Yet that line makes a specific claim: it says something about the history of the page in front of the reader. The claim deserves a source, a meaning, and a person or process that can correct it later. A label cannot be rescued by a plugin field, a sitemap timestamp, a footer copyright year, or an assumption that every edit counts as an update.
This matters because article pages can carry many dates at once. A guide may discuss a policy announced in 2024, include a cited report from 2023, show related posts from earlier months, contain a copyright year in the footer, and have a publication history of its own. Those dates describe different things. When they are allowed to blur together, the page may become confusing for a reader and difficult for a future editor to explain. The goal is not to eliminate every date. The goal is to keep each date in the job it can support.
Begin with the page’s history, not the subject’s calendar
An article date should describe the article page, not automatically the event that the article discusses. A page might explain a conference scheduled for a future month, summarize an older public announcement, or compare several sources published on different days. Those dates may be useful inside the article. They are not, by themselves, proof of when the article was first published or significantly revised.
That distinction is small in wording but important in practice. A reader seeing “Published” normally understands it as a statement about when the page became public. A reader seeing “Last updated” normally understands it as a statement about a later change to that page. Neither label is a generic marker for the newest date visible anywhere in the text. If a team needs to mention an event date, it can do so clearly in the relevant paragraph, table, citation, or event information. The article-history label should remain tied to the page itself.
Google’s byline-date documentation uses the same basic boundary. It describes a byline date as an estimate of when a page was published or updated and says that its systems look at several factors rather than one single date signal. The documentation recommends a visible, appropriately labelled page date and explains that date information may be exposed only when the systems consider it useful to a user. Read Google’s current byline-date guidance. That source explains the boundary; it does not turn a visible date into a display control.
For an editor, the useful question is therefore ordinary and bounded: “What does this date describe?” If the answer is “the first public version of this page,” a publication record may be relevant. If the answer is “a substantial later revision to the page’s information,” an update record may be relevant. If the answer is “a date that happens to appear in a source, example, campaign, event, or related card,” the date belongs in that context instead. Writing down the answer protects the page from a convenient but unsupported substitution later.
Make the visible label say what the reader can understand
Labels have different meanings. “Published” says that the date relates to the first public release of the page. “Last updated” says that the date relates to a later revision. “Reviewed” can describe a check, but it should not silently stand in for a publication or significant-update date. “Current” or “fresh” are broader claims and often leave a reader unable to tell what was actually checked. The narrowest accurate label is usually the least confusing.
A visible label is not decoration. It becomes part of the article’s public information architecture. It appears alongside the heading, author context, introduction, image captions, source list, and calls to action. If the page says “Last updated” but nobody can explain what changed, the reader has received a vague assurance rather than a useful record. If the page says “Published” while the only evidence is an unrelated event date, the label is not doing its stated job. A simple statement becomes more trustworthy when it can be traced to an actual page-history fact.
| Visible wording | The narrow factual meaning | What it does not establish |
|---|---|---|
| Published | The page first became publicly available on the stated date. | That a Search result will show the date, that the page is newly processed, or that the topic itself happened on that date. |
| Last updated | The page received a later, meaningful revision that the responsible owner can describe. | That any visible edit is significant, that a page is automatically “fresh,” or that an external system will react in a specified way. |
| Reviewed | A particular source, statement, or page element was checked at a stated time. | That the entire page changed, that all facts were reverified, or that a publication/update date should be changed. |
Prominence also has a reader-facing purpose. A date buried in an unrelated footer or hidden behind an interaction makes it harder to tell what it describes. Google recommends adding a user-visible date and labelling it appropriately with terms such as “Published” or “Last updated.” The relevant point for this guide is not an instruction to rearrange a specific site. It is that public wording should be clear enough for a reader to understand what the page claims about its own history.
Sometimes a page has no factual date record that can be supported. A team may have inherited content without reliable history, imported an old article from another system, or be unsure whether an apparent timestamp reflects public release, migration, template regeneration, or a real editorial change. In that situation, uncertainty is information. It is safer to record that uncertainty for the accountable owner than to manufacture a date just to fill a visual gap.
Compare visible information with existing Article dates
Article pages may already contain machine-readable information that expresses their publication history. Google’s Article documentation lists datePublished and dateModified among the recommended properties for Article, NewsArticle, and BlogPosting objects. See the current Article structured-data documentation. The presence of these fields does not decide whether they are factually correct, and it does not assure a particular feature or presentation. It simply means that the public page may have another expression of its history to compare.
The comparison should be conceptual before it becomes technical. Read the visible label as a reader would. Then ask what the existing Article date is meant to represent. Is the page’s visible “Published” label consistent with the page’s stated first-publication history? If the article visibly says it was updated, does the existing Article data describe a corresponding meaningful revision? If two values differ, do they refer to different concepts, a timezone difference, a historic migration, an old template, or an unresolved source question? The answer is not always obvious, and a general guide should not pretend to resolve it for a particular site.
Consistency does not mean forcing every date into one stripped-down format. A visible page may present a calendar date that reads naturally to people while the existing Article data includes a time and timezone for precision. Google’s documentation says date and optional time information should match between equivalent visible and structured values, while noting that time and timezone are optional in visible data. The editorial standard is more basic: do not let two public expressions silently contradict one another.
When a page contains both an original publication date and a meaningful update date, the distinction should stay visible. A reader should not have to infer whether the current date erased the older record. Similarly, a page that has not undergone a meaningful revision does not need a new update story invented for it. The public page can be simpler than a publishing database, but it should not be less truthful.
lastmod entry, a server response timestamp, a cache regeneration time, a theme save, and a footer copyright date are different kinds of information. None automatically defines the article’s visible publication or meaningful-update label. The related XML Sitemap Governance guide covers public URL-record boundaries; it does not replace this page-level article-date review.Separate significant information changes from cosmetic activity
Not every change to an article says the same thing to a reader. Replacing a broken citation with a current source, correcting an important factual statement, revising a material explanation, adding a necessary qualification, or removing a claim that can no longer be supported may alter the information a reader receives. Other activities may be operational or cosmetic: a theme reflow, a navigation adjustment, a minor punctuation correction, a cached variant, a background image substitution, or an administrative save that leaves the reader-facing information unchanged.
The point is not to create a universal threshold. Different pages have different purposes, sources, and maintenance obligations. A publication that changes regulated information has a different review context from a general field guide. A specific site may have an editorial policy, legal process, or technical owner that determines how its records work. This guide does not override those contexts. It offers a narrower habit: name the change that is being considered, identify whether it changed the page’s meaningful information, and preserve a record of uncertainty where the answer is not settled.
Google’s publication-date guidance describes a similar caution: it says not to use future dates or dates about the action described on the page, and its earlier explanation says not to artificially freshen a story without significant information or another compelling reason. Google’s publication-date explanation provides the source boundary. It does not authorize an editor to decide that a real site’s date needs changing, and it does not describe a result that follows from an update.
A useful maintenance note can be plain. It might say that a source citation was replaced because the former reference had changed; that an explanation was narrowed because it lacked support; that a material service statement was corrected by the responsible owner; or that a visual caption was revised to match the article’s evidence. The note does not need marketing language. It only needs enough context for a future reviewer to understand why a date question arose.
Watch for dates that look relevant but describe something else
Many article-date errors are not deliberate. They emerge because a page has accumulated several useful but unrelated timestamps. An event date belongs with an event. A source publication date belongs in a citation. A related-post card date belongs to the related post. A footer year describes a site-level copyright notice. An imported record may identify a migration rather than original public publication. A future date might be part of an example, event, or planned change. Each item can be legitimate in its own place. The risk arises when one becomes a substitute for the page’s own history without a factual basis.
Multiple visible dates can also make the reader’s task harder. Google notes that, when a page has followed other byline-date practices but an incorrect date appears to be selected, minimizing unrelated dates may be worth considering. That observation should not be treated as a command to hide useful context. A page may need a source date, event date, or legal effective date. The editorial question is whether the page visually and verbally explains which date is which, rather than leaving a reader or maintainer to guess.
| Date encountered on a page | Question to record | Bounded editorial response |
|---|---|---|
| Future event date | Does this date describe the event rather than the page? | Keep it with the event context; do not treat it as article history by default. |
| Old source or report date | Is it the date of the cited material? | Keep the citation clear and separate it from the article’s own label. |
| Migration or import timestamp | Does it identify a system transfer rather than first public publication? | Record the distinction for the responsible owner; do not guess which history readers should see. |
| Footer year or template timestamp | Does it apply to the entire site or a template? | Do not use it as evidence for a specific article date. |
Ambiguity is not a failure. It is a condition that needs an honest record. A page can say less rather than claim a precise history no one can verify. A content owner can decide whether a page needs a later correction. A developer or platform owner can clarify what a particular system field means. A general field guide cannot know those facts in advance, and it should not conceal that limit behind a confident-looking date.
Keep a small evidence ledger for the public date statement
A long operational database is not necessary for every editorial page. A short record can be enough to make the date claim accountable. It can include the public URL, the visible date wording, the source for the original publication or meaningful revision, the existing Article date information observed on the public page, the owner who can confirm the public fact, the date of the review, and the event that should prompt another look. The ledger should describe what is known and what remains uncertain; it should not contain a prediction about Search presentation or business performance.
The ledger also prevents a common handoff problem. One person may remember when an article was first published, another may update the visible page, and a third may own the technical component that outputs Article data. Without a simple record, each person can assume that someone else verified the date. With a small record, the team can distinguish a confirmed page fact from an implementation question and from an assumption that needs follow-up.
This approach sits alongside, rather than inside, general structured-data governance. The Structured Data Governance for Small Business guide explains the broader visible-fact, source, owner, markup, and public-validation sequence for many kinds of page information. Here, the reader job is smaller: an article’s own publication or meaningful-update record. A narrow role prevents the guide from becoming a generic schema checklist or a substitute for a responsible site-specific decision.
Use public observation without claiming a Search outcome
A final review can stay close to what is observable. Open the public article. Read the visible date label and the nearby heading or byline context. Identify whether the label says “Published,” “Last updated,” or something else. Note the information that supports the label. Observe whether existing public Article date information communicates the same underlying page history. Record an inconsistency, absence, or ambiguity without silently fixing it. These steps document a public-page observation, not a statement about an external system’s response.
This wording discipline matters in release notes, client updates, content calendars, and page copy. “The visible label was compared with the current public Article data” describes a check. “The date was corrected for Search” assumes a result the review cannot establish. “A source record is still needed” identifies a fact gap. “The page is now fresh” turns an editorial label into a conclusion. Precise language does not make the work smaller. It makes the work auditable.
The same restraint applies to page changes. A factual update may make an article clearer for readers. A source record may make a later handoff easier. A visible label may reduce ambiguity. Those are page-level observations. They do not provide evidence about crawl timing, index inclusion, canonical selection, rankings, traffic, leads, conversions, revenue, or another business result. Search systems decide their own presentation, and business outcomes depend on factors beyond a page-date record.
When the honest record is smaller than the page history
Editors sometimes inherit pages with a long, uneven past. A guide may have moved between platforms, changed authors, been copied from an earlier document, accumulated small fixes, or passed through a redesign that altered the surrounding template. The complete internal history can matter to a publisher, but it does not always translate into one simple statement beside the article title. A public label should not pretend to reconstruct a chronology that the responsible owner cannot verify.
In that situation, reduce the claim to the portion that is supportable. A page can retain a clear source citation without asserting an unverified update date. A team can preserve a true publication record without inventing a later “Last updated” label. A reviewer can document that a migration timestamp is known while the original public-release date requires further confirmation. The reader does not need an elaborate explanation of every internal system event; the reader needs wording that does not quietly misstate the page’s history.
This is also why date review should not become a routine way to make older pages look newer. An older article may remain accurate, distinct, sourced, and useful. A recent article may need clarification if its claims are vague or its evidence is weak. The related SEO Content Refresh Workflow addresses the broader keep, revise, combine, or defer decision. This guide does not duplicate that process. It simply asks whether a visible article-date statement has a factual basis when a real review creates the question.
The same careful language is useful when a page has no visible date at all. Absence is not automatically a defect, and a general field guide cannot decide that a particular template needs a new label. The responsible owner may have editorial, accessibility, legal, product, or technical reasons for the current treatment. Record what the public page presents, state what evidence is available, and distinguish a missing fact from a decision that belongs to a site-specific owner. That preserves a useful limit: a local review can describe the public record without becoming a command to change it.
A compact review checklist for one article
- Read the article’s visible date label as a reader would, and write down what the label claims to describe.
- Separate the page’s own publication or meaningful-update history from dates about events, sources, related posts, migrations, templates, and footers.
- Locate the factual source for the claimed page history, or record that the source is uncertain.
- Compare the visible statement with the existing public Article date information as two expressions of the same page fact.
- Describe the change that prompted the review without treating a cosmetic adjustment as an automatic date event.
- Name the person, team, or component that can answer a site-specific date question.
- Record the public observation and leave Search display, crawling, indexing, canonical selection, rankings, traffic, and business outcomes outside the conclusion.
The checklist is deliberately modest. It does not turn a date label into a campaign, a score, or a ranking tactic. It gives a content team a way to handle one public statement with the same care it would give a headline, source link, image caption, service claim, or call to action. When the evidence is clear, the record can state what the page says. When the evidence is incomplete, the record can state that too.
Keep the public record honest
An article date is easiest to maintain when it stays connected to a real page-history fact. A reader can understand the label. An editor can explain the evidence. Existing Article information can be compared rather than treated as a separate source of truth. The accountable owner can decide what a particular site, template, or editorial policy requires. A future reviewer can see why the page was examined without being asked to infer an external outcome.
That is the useful boundary for article dates in Search. Maintain a visible public record that says only what the page can support. Keep event dates, source dates, sitemap records, template timestamps, and publication history in their proper contexts. Compare existing expressions of the page fact, document uncertainty, and refer individual technical decisions to the responsible path. The result is a clearer public statement, not a prediction about how any Search result or business metric will behave.