The SEO APIs allow you to read and write the SEO tags of a Wix site: the titles, descriptions, social share tags, canonical links, structured data, and indexing directives that search engines and social networks read from a site's pages.
Wix manages these tags at three levels, and there's an API for each one. Together they cover everything from a single page's title to a convention that applies across a whole site.
The SEO APIs include:
- Site SEO Tags: Read and write the tags that apply to a site as a whole, such as its default social share image, whether search engines may index it, and the verification tags that prove ownership of the site to a search engine.
- SEO Patterns: Read and write the templates that generate tags for every item of a page type, such as every blog post or every store product. A pattern is written once and filled in with each item's own values when its page renders.
- Item SEO Tags: Read and write the tags of an individual item, such as a page, a blog post, or a store product, and see the tags an item is expected to render with, together with where each one came from.
The tags a page renders with aren't stored in one place. Wix combines several sources, where a later source takes precedence:
- The site's tags, from the Site SEO Tags API.
- The pattern Wix provides for the page type.
- The pattern the Wix user customized for that page type, from the SEO Patterns API.
- The tags of the page that displays the item.
- The tags of the item itself, from the Item SEO Tags API.
This means the same tag can come from any of three APIs, and the most specific one wins. Two practical consequences:
- Work at the level that matches the change. A convention for a whole page type belongs in a pattern; a value that differs for one item belongs on the item. Writing the same title onto a thousand items is the same outcome as one pattern, and much harder to undo.
- To see the result of the combination, read the item. The Item SEO Tags API returns
resolvedTags for an item: the tags it's expected to render with, each marked with the source it came from. That's the only place the three levels are reported together.
Tags that site code, apps, or page components add while a page renders aren't part of this model, so resolvedTags isn't a literal copy of a page's rendered head.
These points apply to all three APIs:
- Changes take effect on the live site without a site publish, with one exception: a static page keeps a draft separately from the published page, so tags written for one are saved to the draft unless you ask for them to be published.
- A write replaces what it targets in full. Retrieve the current tags or pattern first and send back the complete set you want, rather than only what changed.
- There's no revision checking. The last write wins, and a Wix user editing SEO settings in the dashboard writes to the same data. When someone may be editing at the same time, read immediately before writing.
- Coverage depends on which business solutions a site has. A page type or item type provided by a Wix business solution is only available on sites where that business solution is installed. Each API's errors list the types a site supports, so treat that as the current list rather than hard-coding one.
- SEO tag: An element in a page's head that search engines and social networks read, such as a title, a meta description, a canonical link, or a block of structured data.
- Item: Anything on a site that has its own SEO tags, such as a page, a blog post, or a store product.
- Item type: The kind of item, such as
STATIC_PAGE or STORES_PRODUCT.
- Page type: A category of page that shares a pattern, such as a store product page or a blog post page.
- Pattern: A template of SEO tags defined for one page type, whose variables are filled in per item.
- Variable: A placeholder such as
{{product.name}}, written in double braces, that's replaced with an item's own value when its page renders.
- Resolved tags: The tags an item is expected to render with, after combining every source Wix manages.
- Verification tag: A tag a search engine requires on a site to confirm that the person configuring it controls the site.