Indicating alternate versions of localized pages in cross-border stores

Learn how to indicate alternate versions of localized pages.

In this guide, you'll learn how to indicate alternate versions of localized landing pages in cross-border stores to improve SEO and ensure search engines display the correct content for each region.

If your store operates in multiple regions and you have different versions of a landing page for each, you should link them as alternate versions. This practice helps search engines understand the relationship between your localized pages, ensuring they serve the right content to the right audience and improving your store SEO.

When you indicate alternate versions, you must do so in pairs. For example, if you point the US version of a page to a Brazilian one, the Brazilian page must also point back to the US version. This reciprocal linking enables search engines to accurately map the relationship between them, thereby preventing indexing errors.

{"base64":" ","img":{"width":567,"height":438,"type":"png","mime":"image/png","wUnits":"px","hUnits":"px","length":16340,"url":"https://cdn.jsdelivr.net/gh/vtexdocs/dev-portal-content@main/images/vtex-io-documentation-indicating-alternate-pages-in-cross-border-stores-0.png"}}

Follow the steps below for each localized version of your landing page.

Instructions

Step 1 - Getting the route information

In your terminal, install the vtex.admin-graphql-ide@3.x app.
In the Admin, go to Store Settings > Store > GraphQL IDE.
From the GraphQL IDE dropdown list, choose the vtex.rewriter app.
Run the following query to get the internal data for the page path you want to update:


_11{
_11  internal {
_11    get(path: "/{URL}") {
_11      from
_11      declarer
_11      type
_11      id
_11      binding
_11    }
_11  }
_11}

⚠️ Replace the values inside the curly brackets based on your scenario.

Save the returned data.

Step 2 - Updating the route

Clear the previous query and use the following mutation.


_10mutation saveInternal($args: InternalInput!) {
_10  internal {
_10    save(route: $args) {
_10      id
_10    }
_10  }
_10}

At the bottom of the page, click Query Variables.
Complete the Query Variables section following the example below:


_19{
_19  "args": {
_19    "from": "/US/about-us",
_19    "declarer": "vtex.store@2.x",
_19    "type": "userRoute",
_19    "id": "vtex.store@2.x:store.custom::us-about-us",
_19    "binding": "748aafcf-3572-456d-5dec-6ddb3f26e43f",
_19    "alternates": [
_19      {
_19        "binding": "7cf37a3b-efc0-4e47-8201-d8b58kd4d3fd",
_19        "path": "/BR/sobre-nos"
_19      },
_19      {
_19        "binding": "8cf37a3b-edc0-4a47-8241-d8b58kfsd3fd",
_19        "path": "/UK/about-us"
_19      }
_19    ]
_19  }
_19}

For the from, declarer, type, and binding fields, use the information you obtained in the previous section.
In the id field, always set its value from the main binding, even if you're updating the secondary binding's route. This keeps a single canonical reference and prevents duplicate or conflicting entries across bindings. For example, if the main binding has the About Us page at /US/about-us with the id vtex.store@2.x:store.custom::us-about-us, use that same id for the secondary binding's route like /BR/sobre-nos to ensure consistency.
In the alternates field, provide the binding and path for each alternate landing page.

If you don't know the binding values of your stores, follow this instruction guide on checking your account's binding IDs.

Click Run to apply the changes.

Repeat this entire process for each alternate version of the landing page, updating the path in the initial query each time.