Short answer: Google's Article documentation has no required properties, but datePublished, dateModified, author and headline are among the recommended ones. Dates should use ISO 8601 with a timezone, the author name field should hold only a name, and whatever you mark up must match what readers see on the page. This guide is for developers and editors who run a news template. If you need the general Article and FAQ setup first, start with the Article schema markup guide; this one stays on the date and byline problems that news publishing creates.
News pages are different from evergreen pages in one way that matters for markup: they get edited, and the edits have meaning. A correction, a new statement from an official, a changed headline. Each of those raises the same question: what do the machine-readable fields say now, and does that match the story a reader sees?
What Google's Article page asks for
Google's Article structured data page (Opens in a new tab) says an Article object must be based on one of three schema.org types: Article, NewsArticle or BlogPosting. It states that there are no required properties and tells you to add the ones that apply to your content. The recommended list is author, author.name, author.url, dateModified, datePublished, headline and image.
Choosing between the three types
The page lists the three types as supported but does not give a decision chart for choosing among them. The mapping below is our suggestion, not a Google rule. What matters more than the exact choice is that one template always produces one type, so that your reports and tests compare like with like.
| Page | Suggested type | Reason |
|---|---|---|
| Breaking or daily news report | NewsArticle | Describes the page honestly and keeps date fields central |
| Signed opinion column | BlogPosting or Article | Byline must match the printed name |
| Long explainer or special report | Article | Often revised, so edit rules matter |
| Reader comment threads | No Article markup | The main content is not a written article |
Why optional fields still deserve effort
No required fields does not mean every field is equally worth skipping. The page words dateModified and datePublished the same way: add them if you want to give Google more accurate date information. On a news site the date is part of the product, so leaving both out means leaving the machine reading of your most important freshness signal to chance. The documentation also notes that the Rich Results Test does not warn about either property, which means silence from the tool tells you nothing about correctness.
Where the publisher property fits
Publisher is not on the recommended list. It appears only in the author examples as an organization with a name and URL. You can include it, but the publisher information that counts for readers and for Google News sits in visible pages: your masthead, contact details and about page. Our date and byline check for promotional articles on news sites covers how those visible elements are reviewed.
A note on freshness of this advice
Property lists and examples in Google documentation can change. Before you edit a template, open the current Article page and compare its recommended fields with what you output today.
Date fields that go wrong
Date bugs rarely come from misunderstanding the format. They come from defaults: a content system fills a field automatically, nobody checks it, and the wrong value spreads across the archive. Treat the checks below as an audit of defaults.
ISO 8601 and the timezone offset
Google asks for ISO 8601 dates and recommends including timezone information. Without it, the page says, Google falls back to the timezone Googlebot uses. For a newsroom this means a story published late in the evening local time can land on a different calendar day in a machine reading. Always output the offset, and confirm once that the server and the database agree on which timezone they store.
Creation time is not publication time
Many systems store a created-at value when an editor first opens a draft. If the template feeds that into datePublished, the markup will disagree with the timestamp shown on the page whenever a story waits overnight for sign-off. The source for datePublished should be the field that records the moment of publication.
One value for two jobs
Some templates write the same value into datePublished and dateModified, and update both whenever anyone saves. The two fields answer different questions. One says when the story first appeared. The other says when the content last changed in a way that matters. The first should not move during the life of a story.
Bulk operations and migrations
A migration or bulk re-save can stamp the same modified date onto thousands of stories. Readers see no change, but the markup claims fresh updates. Before running any bulk job, check that the template moves dateModified only on editorial edits.
Date audit checklist
- Every date has an ISO 8601 value with an offset.
- datePublished comes from the publish action, not draft creation.
- dateModified moves only on meaningful edits.
- The visible timestamp and the markup describe the same moment.
- Migrations and bulk saves do not touch dateModified.
- Translated pages carry their own dates.
Example scenario: a council vote story
Example scenario: A reporter files a story about a late council vote, the desk approves it the next morning, and the system records the draft time as the publication time. The page shows the morning time, the markup shows the previous night. Nothing is wrong with the story, but two systems now disagree about when it ran. The fix is in the template: read the timestamp written by the publish button and print it with the offset.
Naming authors and publishers
Author fields are touchier than dates because they attach names to claims. Google's helpful content guidance (Opens in a new tab) strongly encourages accurate authorship information, such as bylines, where readers might expect it, and it names fabricated creator profiles, including made-up names and false credentials, as a kind of deception. Markup should only ever describe people and organizations that exist and are shown on the page.
What goes in author.name
The Article page is explicit: in author.name, specify only the name of the author. A job title, an honorific, a publisher name or words like "posted by" do not belong there; separate properties exist for those. The common newsroom mistake is copying the entire byline line into the field, so that the markup says something like "Staff Reporter, Metro Desk" where a person's name should be.
Several authors, or an organization
If the page presents several authors, the documentation wants all of them in the markup, each as its own author entry rather than one merged string. Use Person for people and Organization for organizations. If a story runs under a desk name, the organization type is the honest choice, provided the page itself shows that desk and not a person.
author.url and sameAs
The URL should lead to a page that uniquely identifies the author, and sameAs can serve as an alternative. A working author page is better than a link to the homepage or a category archive. For how to build one, see how to build an author page for E-E-A-T.
What Google News policies add
The Google News content policies (Opens in a new tab) ask for clear dates and bylines, plus information about authors, the publication and the publisher, and about the company or network behind it, with contact details. The policy page does not discuss corrections or updates. Markup repeats visible information; it does not substitute for it.
| Property | Put in it | Keep out of it |
|---|---|---|
| author.name | A person's or organization's name | Titles, locations, "posted by", agency taglines |
| author (several) | One entry per presented author | Names joined with commas in one string |
| author.url | A page identifying that author | Homepage or section index |
| type | Person or Organization, matching the page | Generic or wrong type |
| image | Crawlable image relevant to the story | Logos and caption graphics |
Syndicated and sponsored material
Wire copy, guest columns and paid content each need a decision on who the author is. The News policies require sponsored material to be clearly disclosed and not passed off as independent editorial content. In markup terms: do not credit a staff editor with a sponsored piece, and do not reuse a wire timestamp as your own publication time without saying so in the visible text.
A rule for when dateModified should move
Should dateModified change every time someone edits? No. That is not a sentence from the documentation; it follows from two Google principles taken together. The structured data policies say markup must be a true representation of the page and must be up to date. The helpful content guidance warns against changing page dates to make content look fresh when it has not substantially changed.
Defining a meaningful change
Google does not define it, so your editorial policy has to. A workable definition is any change that could alter what a reader understands or concludes: a corrected fact, a new development, a changed result. Typos, repaired links and layout tweaks usually do not qualify.
| Edit | Move dateModified? | Visible note? |
|---|---|---|
| Spelling or punctuation | Usually no | No |
| Fixing a broken link | Usually no | No |
| Correcting a name, place or figure | Yes | Yes, a correction note |
| Adding a new official statement | Yes | Yes, an update note |
| Replacing a photo without changing meaning | Usually no | No |
| Rewriting or retracting the story | Yes | Yes, an explanation |
The decision rule
Ask three questions in order. Does the change affect what a reader takes away? If not, leave dateModified alone. Does the page show readers that something changed? If not, add the visible note first, because a machine date should not carry a change that readers cannot see. Could you defend this date in a year? If not, do not publish it. How to word the notes themselves is a separate editorial topic.
Visible text versus markup
The Article page contains no sentence that says the visible date must equal the marked-up date. The general structured data policies do say not to mark up content that is not visible to readers and to keep markup faithful to the page. Put those together and the practical rule is simple. If the page says "Updated 2:30 pm", dateModified should show that moment. If the page shows no sign of an update but dateModified is recent, the markup misrepresents the page.
One source, two formats
Print the date for people in a local format and for machines in ISO 8601, but derive both from one stored value. Templates that pull the display date and the markup date from different fields are the most common source of mismatch.
Example scenario: a sports result
Example scenario: A regional site publishes a match report with the wrong scorer credited. An hour later the desk fixes the name and adds a correction line. Here dateModified moves to the time of the fix and the correction line is visible. Later a photo caption gets a spelling fix, and dateModified stays where it was. Readers and machines both see a story with one real correction.
Testing, monitoring and ownership
Markup is only as good as the process that keeps it accurate. The general structured data policies (Opens in a new tab) favor JSON-LD, require markup to match visible content, and say it must be current. They also say the Rich Results Test and URL Inspection catch most technical errors but that some quality problems cannot be found by automated tools. If your Search Console interface is in another language, menu names may look different.
What each check can and cannot tell you
| Check | Catches | Misses |
|---|---|---|
| Rich Results Test | Syntax and property type errors | Wrong or stale dates, wrong person |
| URL Inspection | What Google rendered and detected | Editorial accuracy |
| Manual sampling | Gaps between visible text and markup | Consistency across the whole archive |
| Template test before release | Field mapping mistakes | Old records already in the database |
Pre-release template check
- Pick one sample page per content type: daily news, column, special report.
- Write down the visible date and byline on each.
- Compare them against datePublished, dateModified and author in the markup.
- Run the same pages through the Rich Results Test and URL Inspection.
- Record the results and send mismatches to the template owner.
After release
Keep watching the structured data reports after template changes, and include the manual actions report in your routine. The policies page says a structured data issue can lead to a manual action, which removes rich result eligibility without affecting how the page ranks in web search. It also says Google does not guarantee that correct markup will be displayed. The goal is accurate, consistent data, not a guaranteed appearance.
Who owns what
Write the split down. Developers own field mapping and format. Editors own the correction and update notes. The managing editor owns the policy on what counts as a meaningful change. A one-page agreement between the three avoids relitigating the rules each time the template changes. For the broader structured data picture see the JSON-LD structured data guide.
Writing the policy your template will follow
A template can only be as consistent as the written rules behind it. Newsrooms that leave date handling to developer habit end up with different behaviour on each section of the site. A short internal policy fixes that, and it does not need to be long.
What the policy should state
- Which action sets datePublished, and that it never changes afterwards.
- What counts as a meaningful change, with three or four worked examples from your own desk.
- Which edits require a visible note and what the note looks like.
- How wire copy, guest columns and sponsored items are credited.
- Who may override a date, and how that override is recorded.
Keep the policy next to the template documentation, not in a slide deck. When a developer changes the date logic, the policy is the thing they check against.
Who may override a date
Occasionally a date really is wrong: a story was entered with a mistaken time, or a system outage delayed publication. Allow one named role to correct it, and log who did it and why. Without a log, the next audit finds odd dates and nobody can say whether they are errors or deliberate fixes.
Reading the symptoms
When a problem is reported, work from the symptom to the likely cause. The table below is a suggested order of checks, not a Google classification.
| Symptom | Likely cause | First thing to look at |
|---|---|---|
| Same dateModified across the whole site | Bulk save, or the template prints the current time on render | Source of three old stories |
| Publication date off by one day | Missing offset or mismatched server timezone | The offset in the ISO value |
| Author reads "Metro Desk, Leeds" | Whole byline copied into the field | Author mapping in the template |
| Author link lands on the homepage | No author page, empty value falls back to site root | The author.url output |
| Translated page shows the original date | Language editions read one shared date field | Per-edition date source |
From symptom to root cause
Capture the markup from one broken page and one healthy page. Compare the two to find the first field where they differ. Trace that field to its data source in the template. Fix the template rather than patching individual pages, because a patched page breaks again at the next save if the cause is upstream.
After the fix
Google needs time to reprocess pages, and the documentation gives no fixed duration. Inspect a few sample URLs soon after the fix and follow the reports over the following weeks. Promising a timeline to colleagues would go beyond what anyone can know.
Edge cases: translations, live coverage and archives
The basic rules cover most stories. Three situations need their own handling because the natural defaults go wrong.
Translated editions
If a site publishes Turkish and English editions, each edition has its own markup, date and byline. When the English version is posted a day after the original, its datePublished should reflect when that page went live. Copying the original timestamp creates a mismatch with the visible time on the translated page. Credit the translator or desk only if the page does.
Coverage updated through the day
A page that is edited many times as a situation develops makes the meaningful-change rule hard to apply mechanically. The honest approach is to keep a visible update line and let dateModified follow it. If the page shows several timestamps, make sure the one in the markup corresponds to the latest visible one. The documentation does not describe special rules for such pages, so keep to the general principles above.
Archive rebuilds
Template upgrades often regenerate old stories. Regeneration is not an edit. Make sure the rebuild reads dateModified from the stored editorial value rather than the time of the build, and check a handful of old stories after every site-wide change.
When to leave a field out
If you cannot guarantee a field is right, omit it. The documentation requires nothing, and a wrong author or an invented date does more harm than a missing property. Restore the field once its source is reliable.
Frequently Asked Questions
Can datePublished and dateModified have the same value?
Yes, if the story has never changed after publication. If it has been updated and dateModified still shows the first publication time, the markup does not reflect the page. Neither property is required, but both are recommended.
Should every correction change dateModified?
The documentation has no such rule. We suggest leaving it alone for typos and link fixes and moving it for edits that change what a reader learns, with a visible note. Google's guidance warns against changing dates to look fresh when content has not substantially changed.
Is NewsArticle mandatory for news pages?
No. The documentation supports Article, NewsArticle and BlogPosting and sets no required properties. It gives no strict rule for choosing a type, so pick a mapping for your content classes and apply it consistently.
Can an organization be the author?
If the page presents an organization as the author, mark it up with the Organization type and put only the name in the field. Naming a person in markup when the page shows only a desk name does not match what readers see.
What happens if I leave out the timezone?
Google's page says it will default to the timezone Googlebot uses. That can shift how a publication time is read. Adding the offset to the ISO 8601 value removes the ambiguity.
Does passing the Rich Results Test prove the dates and authors are right?
No. The tool finds syntax and property problems, not wrong facts. The structured data policies also note that some quality issues cannot be found by automated tools.
Related guides: News Site SEO Checklist, How to Write a Corrections and Updates Policy for a News Site, Infinite Scroll or Pagination? A News Archive Guide.
Conclusion
Article markup on a news site comes down to two commitments. First, every field should describe what readers actually see: datePublished the first appearance, dateModified a meaningful change, author the real person or organization named on the page. Second, formats should be unambiguous: ISO 8601, with an offset, and author.name holding nothing but a name. The documentation requires no property and no tool judges meaning, so a short checklist and regular sampling are your real safeguards. If one rule is all you keep, make it this: when an edit does not change what a reader understands, leave dateModified alone.
To get your stories in front of more readers, you can browse ad spaces on Akua Adforce; scope and terms are listed on the product page.
Post a comment
Please log in to leave a comment. Login