A brand dropped, new hours, a holiday: making the change everywhere at once

Four places a store's facts are copied

A store states its facts in four places: the text of its website, its Business Profile, the markup on its pages, and any product feed it sends to Merchant Center. Hours live in the first three, as the location page and the footer, the profile's hours and the location page's markup. Brands live in the text, the markup and the feed: the brands page and the category pages, the Product markup on each product page, and the feed's product data. When one fact changes and one copy is left behind, the store publishes two answers to the same question, and an answer can repeat either of them.

Google asks for the copies to agree in two of its own documents. Its page on AI features lists checking that Merchant Center and Business Profile information is up to date among its practices, and its general structured data guidelines ask for markup to give up-to-date information. A written routine lets a small store keep that promise without rethinking it every week.

A dated page of the brands you carry

The brands page is the one place a shopper, or an answer, can read the whole assortment by maker. Group it by category, spell each brand the way its maker spells it, say which lines you keep in the store, which you sell online only and which you order in, name the locations that stock each one, and date the list. Link it from every category page, and keep a short record of changes at the bottom.

Brands we carry (list changed [date])

[Category]
  [Brand]: [lines] in store at [location]; [line] ordered in, about [n] days
  [Brand]: [lines] online only

[Category]
  [Brand]: sizes [range] in store at both locations

No longer carried
  [Brand]: stopped [date]. We still service [brand] items bought here.

Changes
  [date]: added [brand]
  [date]: stopped carrying [brand]

Move the date when the list changes, and only then. Among the warning signs in Google's guidance on people-first content is a page whose date changes to look fresh while its content stays the same, and a date that tracks the list is also the one a shopper can trust. That is what freshness means for a page like this.

Keep the brands out of places they do not belong. schema.org defines the brand property as the brand "associated with a product or service, or the brand(s) maintained by an organization", so a maker's brand goes on each product's own markup, not on the store's node, which carries a brand only for a house label the store maintains. On the Business Profile, Google's guidelines ask a business that sells another brand's products to use only its own name, without the brand being sold, unless it is an authorized seller dedicated entirely to that brand.

The routine, change by change

Each kind of change touches the same copies in its own way. The table is the checklist; one person owns it and does every column of a row in one sitting.

Within that sitting, the order stays the same whatever changed:

1. Write the change in the log with the date it takes effect.
2. Change the site text: the brands page, the category pages, the location page, the footer.
3. Change the Business Profile: regular or special hours, the services list.
4. Change the feed if you send one, and the markup on every page you changed.
5. The next morning, open the changed pages with scripts turned off and the profile beside them, and tick the row in the log.

Hours in markup: regular, holiday, seasonal and department

In JSON-LD, the location's node is its Store subtype, which makes it a LocalBusiness and lets it carry hours directly. Google's local business page gives the forms: an OpeningHoursSpecification without validFrom and validThrough holds all year, a day closed throughout is "00:00" for both opens and closes, and seasonal hours use validFrom and validThrough together. A department, such as a workshop with its own hours, is a nested item that can carry any of the page's properties. schema.org's own Store example marks holiday dates the same way.

{
  "@context": "https://schema.org",
  "@type": "[BikeStore]",
  "@id": "https://www.example.com/locations/[town]#store",
  "name": "[store name]",
  "telephone": "[number]",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "[street and number]",
    "addressLocality": "[town]",
    "addressRegion": "[state or province]",
    "postalCode": "[postal code]",
    "addressCountry": "[country code]"
  },
  "openingHoursSpecification": [
    { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"], "opens": "[time]", "closes": "[time]" },
    { "@type": "OpeningHoursSpecification", "dayOfWeek": "Saturday", "opens": "[time]", "closes": "[time]" },
    { "@type": "OpeningHoursSpecification", "dayOfWeek": "Sunday", "opens": "00:00", "closes": "00:00" },
    { "@type": "OpeningHoursSpecification", "validFrom": "[holiday date]", "validThrough": "[holiday date]", "opens": "00:00", "closes": "00:00" },
    { "@type": "OpeningHoursSpecification", "validFrom": "[short-hours date]", "validThrough": "[short-hours date]", "opens": "[time]", "closes": "[time]" }
  ],
  "department": [{
    "@type": "LocalBusiness",
    "name": "[department name]",
    "telephone": "[department number]",
    "openingHoursSpecification": [
      { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Tuesday", "Wednesday", "Thursday", "Friday"], "opens": "[time]", "closes": "[time]" }
    ]
  }]
}

Take a holiday entry out after its date, and at the latest on the day you add the next one. An old entry does no work, a list that only grows is one nobody checks, and the entry that matters is always the next one. The markup follows the page: if the location page does not show the holiday hours, the markup does not carry them either.

On the Business Profile, the same dates are special hours. Google's guidelines for the profile ask for regular customer-facing hours and special hours for holidays. A seasonal store sets its regular hours during the season, may say in its description that it opens only for part of the year, and may mark itself temporarily closed off-season. A department with a profile of its own gives its hours there, and the store's profile keeps the store's.

When something ends: what comes down, and what stays

A dropped brand leaves the main list on the day you stop ordering it and moves to the dated "no longer carried" line, with what you still do for past buyers, such as servicing or parts ordered in, stated as your own terms. It comes off the category pages the same day.

A product page for an item that will not return has two honest endings. If shoppers still look for it and the page can say what replaces it, keep it with its Offer availability set to Discontinued, which schema.org defines as an item that "has been discontinued". If not, remove it and let the server say so with the right HTTP status code, or send it by 301 redirect to the nearest category page. Google's pages on status codes and redirects describe how each is treated.

A service that ends, such as rentals or a repair line, keeps a dated note on its page for as long as shoppers still ask for it, and then comes down, off the profile's services and out of the markup as well. So do a sale that has ended, last season's rental prices and a holiday notice after the day: an old page is still a page an answer can read. A location that closes is its own case, covered in the article on businesses with several locations.

The guide for retail stores puts this routine among the other pages, and checking answers against the stock list is the way to see whether a change reached the answers.