대량 메타데이터

마지막 업데이트: 2025년 2월 26일

작성 대상:

  • 관리자
  • 개발자

By default, metadata is managed at the page level. See Authoring and Publishing Content for more information.

In some cases, it is useful to apply metadata en masse to a website. Common use cases include:

  • A certain section of a website should look and feel different from the rest of the website (such as a different template or a different theme).
  • Default metadata such an og:image should be applied to portions of the website.
  • If a certain portion of the website should not be indexed by robots, the metadata can be used to set the robots meta tag to noindex for a portion of the site.

If you want to create metadata for many pages at once, create either an Excel workbook or a Google Sheets workbook in the root folder of your website in SharePoint or Google Drive.

  • Name the file metadata for Google Drive.
  • Name the file metadata.xlsx for SharePoint.

The workbook should have only one worksheet and at least two columns as in the following image.

The column titled URL has the URL pattern of the pages that should get a particular metadata entry.

The wildcard * (the asterisk) can be used as a prefix or suffix, allowing for flexible matches on the URL pathname. Typical examples include /docs/** or **/docs/**.

Note: The metadata sheet is evaluated from top to bottom, site wide meta data set to ** must be before more specific entries.

For each metadata property, create a column in the worksheet and name it using the property you want to assign. Typical examples include template, theme, or robots.

Page-level metadata added via a metadata block takes precedence over bulk metadata. See the documents Authoring and Publishing Content and Metadata (block) for more information.

To explicitly remove metadata a "" can be used as a value. This will remove the element or set the corresponding attribute to "" for a particular path.

Example:

URL          Canonical
/**          ""

The example above will remove the <link rel="canonical"> from all pages by default, unless there is a specific override for example from a page metadata block.

Note: You need to preview / publish the metadata sheet in order to see changes reflected on your page.

Tip: Excel can be slow to update inside SharePoint. If you do not see your changes reflected in preview or publish, hard refresh (click into URL bar and refresh) the Excel document in your browser and preview should work as expected.

Folder-mapped Metadata

If the site has folder mapping configured, the metadata files within that folder will apply to all pages for that mapping. For example, if /templates/ is folder-mapped to /templates/default, metadata in /templates/default/metadata.xlsx will be applied to all pages below /templates/ if the URL pattern matches.

Last-Modified Date

Changes to folder-mapped metadata are not reflected in the last-modified HTTP response header of pages within the mapped scope. By default, the date of the last modification of the default document will be used. If you rely on that header value to be updated based on metadata changes, which may be desirable for SEO or SEM purposes, you can influence* it by adding an explicit last-modified column. This allows you to set the desired date string or timestamp for select rows only while leaving the others unchanged. We recommend the ISO date format to ensure it’s both human-readable and timezone-safe.

Example:

URL         Last-modified
/products/product1  2024-11-21T00:00:00Z
/products/product2  2024-11-20T00:00:00Z
/products/product3  2024-11-19T00:00:00Z

* Note: The actual last-modified HTTP response header is calculated based on the modification times of the contributing resources to the response:

  • The source document itself (for folder-mapped pages, this is the default document)
  • The head.html
  • The global (and additional) metadata
  • The custom headers configuration

The most recent modification time of those resources will be used. This means that the last-modified value provided might not be the final header value if, for example, the head.html is younger.

Additional Metadata

When having metadata that is managed by several teams it is not practical to keep them all in the same metadata files. Multi metadata support is possible by configuring the all the metadata files that need to be taken into account in the /.helix/config.xlsx file:

The order of the entries in the list dictates the order of how the data is applied. The final order of the metadata is as follows:

If there is metadata configured in the /.helix/config.xlsx:

  • Page level metadata block wins over
  • Folder-mapped metadata sheet wins over
  • Metadata sheet(s) in configured order

if there is no configured order:

  • Page level metadata block wins over
  • Folder-mapped metadata sheet wins over
  • Bulk metadata sheet (/metadata.xlsx)

Note that individual metadata properties are overwritten but never deleted. For example, if the /metadata.json defines a property title, the same property in /metadata-2nd.json will overwrite the value, but only if it is not empty.

Experience Manager