Manage SEO

Configure URL Patterns

In Retail Digital Commerce, you can customize the URL structure of your store’s Collection and Product pages so they mirror your SEO strategies.

This section includes the following topics:

Plan URL Patterns

Keep the following points in mind as you plan your URL patterns:

It is best to customize URL patterns when you are planning and testing your store. If you change a URL pattern on your production storefront, you must specify a URL redirect for that pattern. Otherwise, older bookmarked URLs will display an error page instead of the pages you intended.
Each URL pattern must be a valid URL for the page type (Collection or Product) and must contain only components that are valid for the page type. For example, if you include the variable {brand} in the Collection pattern, you will not be able to save your changes because brand is not a collection property.
Each URL pattern uniquely identifies each product and collection via id numbers, or, you can use the URL slug to enter descriptive terms. For example, /product/{=seoUrlSlugDerived}
- descriptive URLs for categories may not be required as, by definition, categories should already have distinctive unique names.
- descriptive URLs for products may be necessary as products can have similar names (slugs) and could, therefore, benefit store maintenance.
Each URL pattern can contain up to 254 characters and cannot contain spaces or special characters except – (dash).
It is best to plan URL patterns bearing in mind that each URL must be unique. This is necessary in order to avoid storefront display issues, such as, 404 errors, or the wrong collection being displayed.

Keep the following points in mind as you plan your URL patterns and your Retail Digital Commerce instance supports more than one language:

Retail Digital Commerce automatically creates URL patterns for each supported language. Retail Digital Commerce uses your catalog translations for the variables values, but you must manually translate any words that are not variables. For example, in the default product page URL pattern, you must manually translate the word product. For more information, see Localize Your Store.
Although it is possible to configure a different product and collection page URL pattern for each language supported by your site, it is recommended to maintain URL pattern consistency between each language. This allows you to translate any fixed parts you many have in your URL patterns for each language.
There is a language prefix (a language subdirectory) that is automatically included for each additional language supported by your site. This subdirectory is not included in the default language URL structure for a multi-lingual site. For example, if you support 3 languages for your site: English, Spanish, and French, with English being the default language, your URL structures will be as follows:

English URLs: www.example.com/my-url-patterns

Spanish URLs: www.example.com/es/my-url-patterns

French URLs: www.example.com/fr/my-url-patterns

Understand Default URL Patterns

By default, Retail Digital Commerce uses the following URL patterns for Category and Product pages:

Collection page: /{seoTitleDerived}/category/{id} For example, /cameras-and-camcorders/category/cameracat.

Product page: /{seoTitleDerived}/product/{id} For example, /striped-button-down/product/prod10001.

Understand URL slug patterns

Clicking the Build URL Slugs button generates a URL mapping table, allowing the slug value to be used as a unique url pattern identifier instead of the {id} property.

This enables you to define the URL patterns with a descriptive slug value, prefixed with ‘=’. The ‘=‘ symbol is used with the seoUrlSlugDerived pattern only and ensures that the specified products and collections are returned from the server, as highlighted below:

Collection page: /category/{=seoUrlSlugDerived}, for example /category/cameras-and-camcorders.
Product page: /product/{=seoUrlSlugDerived}, for example, /product/samsung-f90bn-hd-flash-memory-camcorder.

Customize URL Patterns

To customize URL patterns for your store:

Click the Settings icon.
Select Setup and then click the URL Patterns tab.
If your Retail Digital Commerce instance runs multiple sites, pick a site to configure from the list at the top of the settings list. See Run Multiple Stores from One Retail Digital Commerce Instance for more information.
Click the Collection Page URL.
Type the new pattern and click the Save icon when you are done.

Note:

URL slug values must be unique, if not, a warning message is displayed indicating that this must be the case.

Variables must be inside {} (curly braces, for example, {id} or {seoTitleDerived}). For a list of variables for Collection Page URLs and Product Page URLs, see the tables that follow this procedure.
(Optional) Check the Auto Redirect box so that shoppers who have bookmarked older URLs are automatically redirected to the new URL. Auto Redirect is selected by default and will only redirect from the default URLs, not from previous patterns.
If you want to use URL slugs rather than IDs in your URLs, you will need to click the Build URL Slugs button.
(Optional) You can simplify your URL slugs by clicking the Build URL Slugs button. You will notice that the most recent date and time the URL slug table was built is displayed. Simplifying URL slugs removes any special characters, replaces spaces with hyphens, and simplifies into lowercase. Once the simplified URL slugs have been built, you will need to manually update the URL pattern to use the new URL slug. For example, "/product/{=seoUrlSlugDerived}".

Note:
If a warning displays informing you that URL slugs are not unique, then a uniqueness check can be performed in order to fix this issue. See Perform uniqueness checks for URL patterns for details.
Click the Product Page URL and repeat steps 4 – 6 to update the URL pattern for the product page.
Check if the URL pattern was changed by clicking through your store. You may also wish to check that redirected URLs work correctly.

The following table describes the available properties for Collection Page URL patterns. Each property displays the value of the corresponding collection property. For more information about collection properties, see Organize products in collections.

Collection Page URL Variable	Description
displayName	The collection’s Name property. (A short, descriptive name that identifies the collection.)
Id	The collection’s ID property. (The ID that identifies the collection internally.)
Description*	The collection’s Description property. (A short description to display with the collection.)
parentCategory	The display name of the collection’s current parent.
seoDescriptionDerived*	The collection’s Meta Description property. See Add metadata to products and collections for more information.
seoTitleDerived*	The collection’s Title Tag property. See Add metadata to products and collections for more information.
seoUrlSlugDerived	The collection’s URL Slug property. See Add metadata to products and collections for more information.

* These variables should not be used as queryable elements in URL patterns (that is, they are not included in Build URL Slugs).

The following table describes the available properties for Product Page URL patterns. Each variable displays the value of the corresponding product property. For more information about product properties, see Understand the base product type.

Product Page URL Variable	Description
displayName	The product’s Name property. (A short, descriptive name that identifies the product.)
Id	The product’s ID property. (The ID that identifies the product internally.)
Description*	The product’s Description property. (A short description to display with the product.)
parentCategory	The display name of the product’s current parent collection.
Brand	The name of the manufacturer.
Type	The product type. If the product was created with the Base product type, this value is not displayed. See Create and edit product types for more information.
seoDescriptionDerived*	The product’s Meta Description property. See Add metadata to products and collections for more information.
seoTitleDerived*	The product’s Title Tag property. See Add metadata to products and collections for more information.
seoUrlSlugDerived	The product’s URL Slug property. See Add metadata to products and collections for more information.

* These variables should not be used as the elements in URL patterns.

Perform uniqueness checks for URL patterns

The uniqueness of URL patterns plays a significant role in ensuring your site does not encounter storefront display issues, such as 404 errors or the wrong collection being displayed. Therefore, you must ensure the URL patterns used produce unique URLs for each product and category.

It is worth noting that the uniqueness check for URL patterns is required only when you have clicked the Build URL Slugs button and you are using {=seoUrlSlugDerived} in your URL pattern.

You can use the Catalog export file to check that categories and/or products do not have a shared URL slug value. To do so:

Go to Catalog and click the Export button to export the Catalog data.
Select the item you wish to export and click Export. This exports the data in the form of an Excel spreadsheet.
Open the Excel data.
Scroll to the seoUrlslugs column and sort alphabetically.
The seoUrlslugs column may not contain any data; this happens only when URL slugs have already been built.
Identify instances that are identical, and do one of the following:
Either
Edit the values for the duplicated seoUrlslugs within Excel, and click Save. You must then click Import, choose the edited file, and click Upload File. Click the Validate button to confirm.
Or
On the Catalog page, open the product with the duplicated URL and go to the Metadata tab. To change the current information, check Edit Manually and enter the text within each box. You can change back to the default alt text by checking Edit Manually and clicking Reset Default.
Click Save.

Note:

The uniqueness check procedure is automatically performed when the Build URL button is clicked, producing a list of duplicates via the API response. However, you can continue to perform the above procedure as required.

Customize SEO Tags

Retail Digital Commerce provides the option to modify meta tag patterns, or customize the meta tags on any static page. Meta tags are placed within the code of your web store pages and provide additional information to the search engine. They control how, and suggest what, results get displayed in the search results.

Web search engines partly base their rankings of pages on the words that appear in certain HTML tags, particularly <meta> tags and the <title> tag.

A common SEO technique is to list key search terms in those tags in order to raise the ranking of the pages for those terms. While you should avoid “keyword stuffing” – that is, overloading tags with content and keywords that are not helpful for shoppers, especially keywords that have nothing to do with the content of your store – you can customize these tags.

This section includes the following topics:

Tag Store Pages

Meta title and meta description optimization play a vital role in SEO as both elements are displayed in the search results. The meta title tag is taken into consideration in the ranking process. The meta description is used by Google in Search Engine Results Pages (SERPs) snippets, and may encourage users to click on your page, thereby potentially impacting your click-through rate.

Retail Digital Commerce automatically adds <title>, <meta name="keywords">, and <meta name="description"> tags to the headers of several types of pages on your store.

For each product and collection page in your store, Retail Digital Commerce sets the default values of SEO tags to the following:

<title> tag: The value of the Name property of the product or collection.
<meta name="keywords"> tag: The values of the Name and Parent Collection properties of a product. The values of the Name and Selected Parent properties of a collection.
<meta name="description"> tag: The values of the Name and Description properties of the product or collection.

You can customize the metadata for these tags when you edit a product or collection on the Catalog page in the administration interface. To learn how to customize the metadata that Retail Digital Commerce automatically turns into tags, see Add metadata to products and collections.

For content pages, such as the home page and article pages on your store, Retail Digital Commerce sets the default values of SEO tags to the following:

<title> tag: The value of the Site Name property.
<meta name="keywords"> tag: By default, there is no metadata in this tag.
<meta name="description"> tag: By default, there is no metadata in this tag.

You can customize the metadata for these tags when you edit a layout on the Design page in the administration interface.

Customize URL Slugs

A URL slug is the SEO-friendly, human-readable part of product and collection page URLs. Retail Digital Commerce automatically creates a URL slug for each product and collection page that is set to the value of the Name property for the product or collection.

You can customize the URL slug when you edit a product or collection on the Catalog page in the administration interface. For example, you could edit the slug to exclude special characters that can cause problems for robots that index your pages, and re-test to see if the problems reoccur. To learn how to customize a URL slug, see Add metadata to products and collections.

Tag Metadata for Images

An alt attribute attached to an image file helps search engines understand what the image shows, and rank it in the image search. Images can deliver a significant part of site traffic so it is worthwhile to use descriptive:

file names - rename the file before uploading to the Retail Digital Commerce, for example, red-bag.jpg is better than 3847539.jpg.
alt attribute - a few words describing what the image presents. Alts and title attributes can be customized via a bulk CSV upload.

Retail Digital Commerce automatically adds alt text and title attributes to the <img> tag for each image on a product or collection page on your store.

Search engines index alt text and use it to return images for user queries. Alt text is also used when shoppers cannot view images on the web. For example, a blind shopper’s screen reader reads an image’s alt text when it reaches the image on a category page on your store.
A title is used as a tooltip, or hover text, when a shopper points to the image.

By default, both attributes are set to the value of the Name property for the product or collection. You can customize the alt text and title when you edit a product or collection on the Catalog page in the administration interface. See Add alt text and titles to images for more information.

Add Open Graph Tags to Product and Wish List Pages

The Product Social Meta Tags widget automatically adds Open Graph (OG) protocol meta tags to product pages to control the content displayed when a page is shared on Facebook. To learn how to customize the Product Social Meta Tags widget, see Share using email, Facebook, Pinterest, or Twitter and Product Social Meta Tags.

You can add custom tags to the header of any page by creating them in the Additional Meta Tags section of the page layout. To learn how to customize metadata for page tags, see Design Your Store Layout.

Manage SEO Content

Retail Digital Commerce enables you to manage the SEO content within your store by providing configurable title and meta descriptions, headings, category and product descriptions, accessible content, and product variants.

Generate Title/Meta Description

Retail Digital Commerce provides auto generated title and meta descriptions for the display name, brand name, and body content of your store. You can configure patterns based on default or custom fields for each page type, with each static page displaying a preview of how your page snippet will look in search results.

Duplication of SEO tags, where the same title or meta tag value is propagated across pages of a given type, should be avoided. It is good practice to customize your homepage title and meta description as title tags are taken into account in organic rankings. Whilst meta descriptions suggest to Google what should be displayed in an organic snippet. To optimize your meta descriptions you should highlight product features for a higher click through rate.

Headings

Retail Digital Commerce supports unique heading tags (H1-H6) on each page type. The heading tag default settings are:

<h1> - product/category name or page title
<h2> - your product or category description field value
<h3> - inside the main unique body content; not to be used for repetitive site-wide widgets
<h4> - <h6> tags are used in the remaining site-wide page elements (such as reviews, similar products, and so on.)

When planning heading tags for your Retail Digital Commerce site, keep in mind the following points:

place primary keywords inside H1 headings, secondary keywords are allocated in H2 headings.
H1-H2 tags with the highest importance should be unique. Therefore, it is advisable to make key headings different from the page title. In particular, H1-H2 tags should be planned out for the homepage, product, category, and static article pages.
customize the H1-H6 placements directly within in the widget source code.
avoid constraining heading placements with CSS styling.
ensure heading tags do not make any changes in page layouts.

Category/Product Descriptions

Each category or single product page should have a unique description as it is recommended to tailor your site copy without duplication from the product details. For example, category descriptions can be placed at the bottom of the page to achieve usability on mobile and for the benefit of SEO.

Content Accessible to Web Crawlers

To aid accessibility on mobile devices, ensure your most relevant content is instantly visible once a user lands on a page. Copy hidden under a “see more” link, or beneath tabs, must be present in the prerendered version of the page.

To view the DOM of a prerendered page:

Open Chrome Developer Tools and navigate to the Network tab.
Switch the User-Agent to Googlebot and reload the page.
Click on the Elements tab. You will see the prerendered version of DOM.

Note:
If you use onClick or onScroll events to load additional content on the page, it will not be included in the prerendered version of DOM.
Search the DOM to check if the content has loaded.

Note:
If you use video or images, it is recommended to always provide captions, ALT/TITLE attributes and transcriptions for video content.

Product Variants

Multiple variants of the same product should be published under one URL page to avoid duplicate content issues. This is the case when there is little that differentiates the product - such as color, size, pattern, and so on. It is also recommended to use drop downs and selectors to help shoppers pick their product features on a single product page. Sizes are most often implemented as a drop down with a URL that does not change, or with a parameter added to create a URL canonicalized to the primary product URL.

For instances when a product type may be perceived as two different items, products can be submitted as separate indexable URLs, especially if a shopper is more likely to use the variation of the product in their searches. For example, a product such as an eyeshadow with two unique variant names would be two different items. In this case, each variant = unique indexable URL. You may want to consider the number of potentially duplicate product variants that can result from adding separate indexable URLs for each variant.

Understand Canonical Tags

Each of your web store pages has a canonical link (or tag) embedded within the head section code. This link signals the source, or original, URL of a page to search engines.

Use Canonical Links

When a given page on your web store can be accessed via several URLs, then the canonical link indicates to search engines which version of that page is the original version. This is also the case when there are multiple pages with different URLs containing only slight content variations.

The use of canonical links within your web store pages improves search engine rankings as search engines use them to consolidate links to duplicate, or similar, content. This means they assign a higher ranking value to those pages marked as the source URL.

An example of how this may look on your site is outlined below.

Say a robot lands on the following link:

http://www.mystore.com/shoes/category/mens_shoes

In the <head>, this page might include the canonical URL

<html>
<head>
<link rel="canonical" href="http://www.mystore.com/shoes/category/mens_shoes">

If a robot follows a link somewhere that lands the same page, but with a different address, such as:

http://www.mystore.com/footwear/category/mens_shoes

The canonical URL would point to the first category.

<html>
  <head>

           <link rel="canonical" href="http://www.mystore.com/shoes/category/mens_shoes">

Use Canonical and Pagination Tags

Retail Digital Commerce provides two different pagination layouts: numeric (default), or rel="next" and rel="prev" links.

For the first page in a sequence on the numeric pagination layout, you will see a normal request for the category page and a request for page zero of the sequence. Zero should be used to display the first batch of content on the product listing pages. All canonical tags on paginated pages in a sequence should be self-referential, so the URLs might look like www.example.com/category/c1234, www.example.com/category/cshoes/2, www.example.com/category/c1234/3, and so on. The rel=canonical attribute for “/1” will point to the page zero category page URL.

If the page type is "Article," then a non-parameterized self-reference is added.

Each shopping and article page contains a <link> element with the attribute rel="canonical". If the page type is:

‘Home’ then the canonical attribute points to https://www.hostname.domain.
‘Product’, then a self-reference is added to the non-parameterized version of that product detail page.
‘Collection’, then canonical elements are added based on whether or not the listing includes pagination, as described earlier: page zero, page /2, page /3, and so on.

The pagination layout with the HTML attributes rel="next" and rel="prev" indicate to search engines that the relationship between individual URLs should follow a logical sequence. These are automatically added when there is more than one page displaying items from one Collection.

If there is a previous page in the sequence, you will see the rel="prev" element referring to the previous page.

If there is a next page in the sequence, you will see the rel="next" element referring to the next page.

Therefore, aside from page “zero” and the last page in a given sequence, all in-between compound pages will contain both rel=”prev” and rel=”next”.

Making changes to your pagination configurations can result in some of the subsequent URLs being inaccessible to search engines. For example, you may want to use an infinite scroll to load additional items in a Collection, however, search engine crawlers do not scroll so everything that appears after an event of scrolling will not be discovered by the crawler. Therefore, you should not remove your pagination links from mobile views, and prior to your site launch you should always verify they work. The numeric pagination layout provides optimal SEO for all store types, whereas the rel="next" and rel="prev" links work best where there are 1 or 2 paginated pages.

Use Canonical and Language Tags

When at least one additional storefront language exists, then the 'hreflang' tag is added to all pages. Regardless of whether a multi-lingual store uses directories or subdomains, 'hreflang' annotations must be used as these signal the relationship between multi-lingual sites. Canonical tags across different language sites should always be self-canonical.

Understand SEO Snapshots

SEO generates static snapshots every 24 hours or whenever changes are published. These snapshots provide a prerendered copy of a storefront page. However, as Retail Digital Commerce does not have control over how often a crawl happens, search engine results are not guaranteed to reflect the latest changes.

Retail Digital Commerce generates HTML snapshots consistently throughout this section of your site, so you can be sure that signals sent to search engines are consistent. The default setting ensures prerendered snapshots are served to Googlebot and other search engine bots. However, you can modify your preferences and decide whether JavaScript client side rendered, or HTML, snapshots should be served to other crawlers.

As Retail Digital Commerce uses a JavaScript framework it is worth noting that all search engines have some limitations in terms of processing JavaScript and rendering JavaScript- heavy pages. In order to help search engines with crawling and indexing, Retail Digital Commerce renders the page and static snapshots of your pages directly to the search engine crawlers. These snapshots provide a prerendered copy of a storefront page. Prerendering aims to speed up the indexing of fresh content published in your store, such as, new product or collection pages.

Search engines (such as Google) regularly update URL information based on a strict timeout. When pages are provided to Google after the timeout, the request is canceled and the page is not updated. Therefore, Retail Digital Commerce uses prerendered snapshots in order to ensure storefront pages are delivered to Google as quickly as possible.

Retail Digital Commerce generates an already-rendered version of a storefront URL and stores a static copy of the page (excluding dynamic elements or JavaScript) on the server to ensure a fast retrieval. Note also that Retail Digital Commerce generates distinct snapshots for both mobile and desktop.

Configure URL Redirects

You can configure URL redirects for your site that specifically relate to 301 and 302 browser response codes, indicating that your redirected URL has either permanently or temporarily moved, respectively.

In the case of a 301 redirect, the URL is moved to a new target permanently. This type of redirection can help with moving the SEO authority from the old URL to the new equivalent. The following example illustrates a 301 redirect with an example site base URL: www.example-shop.com/example with the redirection rule:

originUrl: /smartphones/collection/id1234?show=all
targetUrl: /fr/smartphones/collection/id789?show=20

It is worth noting that 302 redirects are the preferred choice if you want to redirect a page for a limited amount of time.

URL redirects are created/deleted using the createRedirect and deleteRedirect endpoints in the Admin REST API. The total number of entries in the database defaults to 1 million. Should you require more than that, contact Oracle Support.

URL redirection rules can be setup on a per site basis as each of the URL redirects are relative to the site base URL. If a siteId is not provided, then the rule acts as a global redirect for all sites. The following table describes the properties for redirecting URLs:

Parameter

Description

originUrl

Origin URL of the redirect.

siteId

ID of the site to which the redirect belongs.

type

Redirect type (301 or 302).

targetUrl

Destination URL of the redirect.

Query parameters are not copied from the origin to target URL, instead you are required to include them in the definition of the redirect rule. When deleting a URL redirect, you specify the ID of the rule to delete using the path parameter of the deleteRedirect endpoint. For example: DELETE /ccadmin/v1/redirects/30001.

The following example illustrates a 301 redirect:

POST /ccadmin/v1/redirects HTTP/1.1 
Authorization: Bearer <access_token> 
Content-Type: application/json 
{ 
"originUrl": "/smartphones/collection/id1234?show=all", 
"siteId": "siteUS",
"type": 301,
"targetUrl": "/fr/smartphones/collection/id789?show=20"
}

See the Retail Digital Commerce REST API documentation in the Oracle Help Center for more information.

Edit the robots.txt File

The robots.txt file controls how web robots access and index your store’s pages.

For more information about robots.txt and the Robots Exclusion Protocol, visit www.robotstxt.org.

If you run multiple sites within a single instance of Retail Digital Commerce, each site has its own robots.txt file. See Configure Sites to learn how to create multiple sites.

To view your store’s current robots.txt file:

Enter the following URL into your browser:
https://[store url]/robots.txt

where [store url] is the base URL for your store.
Retail Digital Commerce displays the contents of the current robots.txt file.

If you run multiple sites and keep language versions in directories, for example, example.com/de/, example.com/es/, you do not need to create a separate robot.txt file for each version. This is only the case for multiple sites over sub domains.

The Retail Digital Commerce robots.txt file below shows the updated contents after these recommendations have been made:

User-agent: *
Disallow: /cart
Disallow: /en/cart
Disallow: /checkout
Disallow: /en/checkout
Disallow: /profile
Disallow: /en/profile
Disallow: /searchresults
Disallow: /en/searchresults
Disallow: /confirmation
Disallow: /en/confirmation
Disallow: /wishlist_settings
Disallow: /en/wishlist_settings
Disallow: /wishlist
Disallow: /en/wishlist

Sitemap: http://[store url]:8080/sitemap.xml

User-agent: * means that the exclusion rules should apply to all robots. You can replace the * (asterisk) with the name of a specific robot to exclude, for example, Googlebot, or Bingbot.

Each Disallow: /[page] entry indicates a page that robots should not visit. You should not remove any of the Disallow: entries from the default robots.txt file, though you might want to include additional pages that you want robots to ignore. If you are testing your store and do not want any robots to crawl any pages, you might want your robots.txt file to look like this:

User-agent: * Disallow: /

If you plan to use your staging site as your production site when development and testing is complete, you will need to change the content in the robots.txt file to the custom settings presented above. If you tested on a separate staging domain, Retail Digital Commerce inputs a valid default robots.txt for you for your production storefront when you go live.

You cannot edit the robots.txt file in the administration UI. You must edit it with the Retail Digital Commerce Admin REST API. See Use the REST APIs for information about the REST APIs.

To update the robots.txt file, issue a PUT request to /ccadmin/v1/merchant/robots. The body of the request must include the entire contents of the file, in text/plain format.

When you update the robots.txt file, it will not be overwritten until the next PUT request is sent to /ccadmin/v1/merchant/robots.

If you run multiple sites within a single instance of Retail Digital Commerce, you must specify the site whose robots.txt file you are updating in the x-ccsite header in the PUT request. If you do not specify a site, the request updates the default site’s robots.txt file.

The following example shows a PUT request that adds your error page to the list of pages for robots to ignore.

PUT /ccadmin/v1/merchant/robots HTTP/1.1
Content-Type: text/plain
Authorization: Bearer <access_token>

{
User-agent: *
Disallow: /cart
Disallow: /checkout
Disallow: /profile
Disallow: /searchresults
Disallow: /confirmation
Disallow: /wishlist_settings
Disallow: /wishlist
Disallow: /error
Sitemap: http://occs-host/sitemap.xml}

Note:

The XML sitemap is an index of page URLs on your store that is available for crawling by search engines. It helps search engines to crawl your site more intelligently. Only pages, products, and collections that can be seen by anonymous shoppers (that is, visitors to your store who are not logged in) are included in the generated sitemaps. Each sitemap.xml includes a <lastmod> tag that provides the date and time the item was last published. See Understand XML sitemaps for more information.

Upload a Custom robots.txt File

The updateRobotsFile endpoint allows you to upload a custom robots.txt file. However in previous versions of Retail Digital Commerce, when publishing or on startup, the RobotsManager automatically replaced this custom robots.txt with an auto-generated one. In this case it was advisable to contact support who were required to manually disable automatic robots.txt generation.

From the current version of Retail Digital Commerce, the updateRobotsFile endpoint automatically disables the automatic robots.txt file generation. Additionally, the new endpoint /ccadmin/v1/merchant/seoConfig allows you to query, or update, the status of automatic robots.txt file generation.

Understand Internal Search Results Pages

Internal search refers to the search option on your own website when internal search results pages are generated. To prevent creating low-quality pages, internal search results are excluded from crawling in the robots.txt file and are not found in Search Engine Results Pages (SERPs).

Note:

You can use Google Analytics to track internal search queries and use the reports to regularly monitor for:

the discovery of new keywords that customers use when searching for your products.
hints of navigational issues - users may be looking for existing categories that are difficult to find in your main navigation.

Customize Structured Data

Retail Digital Commerce automatically generates a valid markup for the homepage, product, and collection pages with: Products, Breadcrumbs, ItemLists, Reviews, WebSite, and Organization properties.

The functionality to highlight page elements on certain template types and display in Search Engine Results Pages (SERPs) is limited to Google only. Therefore, your markup would not be seen by other search engines. Retail Digital Commerce enables you to switch off the default markup for given page types, and substitute it with your custom script template that utilizes values from Commerce variables.

JSON-LD is Google’s recommended implementation. When customizing your JSON-LD, include as many applicable properties as possible to create different structured data templates for different product types in your store.

You can use the Structured Data report in the Google Search Console to monitor how Google interprets JSON-LD scripts across your store, and check for any markup errors and warnings referring to missing properties. You can also verify how Google sees structured data on a per page basis.

Understand XML Sitemaps

Retail Digital Commerce auto generates valid XML sitemaps for all of your store pages, or resource types.

Retail Digital Commerce resource types include:

product
category
static pages
video
images
supplementary pages: blog/lifestyle section

Determine Page Visibility Settings

These settings will determine whether a URL appears in an XML sitemap:

Active

This option hides a given page from the shopper. If a previously published product is deactivated, you will be prompted to specify its redirect path. If you deactivate a category, you are prompted to provide a direct path and warning displays indicating that you are about to orphan your products. These will then be displayed in a separate folder for you to assign to other active categories
Meta robots directive

Retail Digital Commerce provides two options: index,follow (default) and noindex,follow. The latter will exclude the page from Google search results, but crawlers will still follow and crawl any links on that page.
Canonical tag

This should be self-referential (default setting), or your custom URL.
Exclude from Sitemap

This allows you to exclude specific pages from being included in XML sitemaps.

Your XML sitemaps should be submitted in Google Search Console and Bing Webmaster tools. If your store’s static image assets are hosted externally/on subdomains then additional hostnames should be verified in Search Console, and XML image sitemaps submitted for those properties. Any possible crawling issues related to images can, therefore, be monitored.

Note that sitemap URLs are generated automatically by Retail Digital Commerce for all of the locales that correspond to a given site.

Work with the Image XML Sitemap

A separate XML image sitemap file utilizes both required and optional sitemap tags to indicate to search engines which site images are to be crawled and indexed. By default, only key body images, such as, product photos or homepage banners, are included in XML sitemaps. Additional tags are utilized to include the image caption and title.

Images are also included in the default structured data output in JSON-LD. Retail Digital Commerce allows the customization of ALT and TITLE image attributes through editing single images in the Media section, or bulk CSV upload. The default values for product imagery include:

ALT → product {displayName}
TITLE → product {description} (short)

ALT and TITLE image attributes should be unique and not duplicates of product display names or descriptions. It is recommended that you do not use too many keywords or repeat the same attribute content. All product images should have descriptive file names prior to being uploaded, and dashes should be used to separate words, for example, example-phone-v2-C328.jpg should be used instead of image_8974.jpg.

Note:

You should avoid embedding copy into banners as this is illegible to web crawlers. Instead, overlay text on top of imagery as only the ALT and TITLE attributes can be interpreted. Also avoid using CSS background images and instead use standard HTML <img src=””> to add imagery that you want to appear in search results (namely all product photos on both product/collection pages). To add design elements, such as, arrows, bars, small icons, and so on, you can use the CSS background property.

Verify the XML Sitemap

You can verify the validity of all your domains and subdomains in a search engine, such as Google Search Console.

Submitting a valid XML sitemap file will influence how quickly your pages are crawled and subsequently indexed. Google's Index Coverage report provides feedback on how quickly new URLs are being processed.

Note:

You should allow some time for this information to finalize as even though Googlebot may have seen your URLs, it does not mean they will be automatically included in the index.

Sitemap submissions for larger sites enables you to verify the most important directories of the main site as separate properties for easier monitoring. For multi-site store directories, you can verify the language subdirectories as separate properties.

Understand SEO Localization

Retail Digital Commerce platform auto generates hreflang tags that adhere to Google guidelines. The hreflang tags enable search engines to serve the correct regional or language URLs in search results based on the searcher's country and language preferences.

Plan your Targeting

You are required to specify how many countries and language variants your site will target. Consider how many translations you will be able to provide - you could target 20 countries, but you may only have to provide English, French, and German language variants.

You will also need to decide on the number of country top level domains (cTLDs) your site will incorporate under one Retail Digital Commerce panel. cTLDs such as .co, .uk, .ie., or .pt will typically target their relevant country only, however, they are all perceived to be equal by Google, so there is no disadvantage in terms of rankings to gain organic visibility with a domain.co.uk on google.com.

You may also choose to target multiple languages and locales from one gTLD only (.com, .org, .net), for example, example.org/en-gb/, example.org/en-au. Your final choice will also depend on the collection of domains already in use by your business.

When URL structures are planned out, country URL prefixes should not be used as they are redundant. For example, example.com/us-kitchen-accessories/or example.com/us-pottery/.

They do not contribute to the overall understanding of what a given page is about. If the same domain is to target other languages/countries, subdirectories are recommended (rather than subdomains).

Monitoring

Google Search Console allows to verify your language and locale targeting settings in the Search Traffic, International Targeting report. The Language report can list up to 1,000 errors with your hreflang implementation:

Note:

For single language stores: if your domain is a generic TLD, you will be able to specify your site-wide language setting.

Content Localization

The purpose of multi-language stores is not only to translate the contents to cater to different markets, but also to make content suited for the locales you wish to target. The process of localization should go beyond translation only: accepting payments in local currency, adding payment methods specific to a locale, adjusting delivery information for each geographical location, using appropriate measurement systems. Also, you should always ensure that you adjust any visual communications to suit different cultures accordingly.

Control Access to Storefront Servers

In addition to the servers running your production storefront, you may have various other storefront servers used for development, testing, and staging purposes.

To prevent unwanted access to your storefront servers by web crawlers and other processes, Retail Digital Commerce provides a basic authentication system. (This system does not apply to administrative servers, as these servers already require OAuth 2.0 authentication to access any content.) The basic authentication system checks various values associated with an incoming request, such as the hostname, client IP address, and headers. If any of these values is specifically allowed, the request is accepted without a challenge, but if not, a dialog is displayed for entering a username and password. For example, your production server is typically configured to bypass authentication if the request is sent to the official site URL (such as www.example.com), but the dialog is displayed if the request is sent to the internal hostname (such as ccstore-xxxx-xxxx.oracleoutsourcing.com).

The primary purpose for the basic authentication system is not security, but rather to prevent accessing the servers in an unexpected way. For example, if a web crawler accesses a test server, the authentication system prevents it from indexing pages, so that web search results do not direct shoppers to that server. On the production server, web crawlers are permitted to index pages, but only when the pages are accessed via the official site URL.

Note that the basic authentication system is completely separate from any shopper login. On your production server, shoppers should never see the authentication dialog unless something is misconfigured.

Your servers are configured by default to display the authentication dialog only when appropriate. You should typically not need to make any changes to the configuration. However, the Admin API does include endpoints you can use to make changes to the configuration, including the username and password, allowed headers, IP addresses, and hostnames:

To see your current settings, use the getBasicAuthConfiguration endpoint.
To change your settings, use the updateBasicAuthConfiguration endpoint.

For more information about these endpoints, see the Retail Digital Commerce REST API documentation on the Oracle Help Center:

https://docs.oracle.com/en/industries/retail/index.html

7 Manage SEO

Configure URL Patterns

Customize SEO Tags

Manage SEO Content

Understand Canonical Tags

Understand SEO Snapshots

Configure URL Redirects

Edit the robots.txt File

Customize Structured Data

Understand XML Sitemaps

Understand SEO Localization

Control Access to Storefront Servers