Guide 12 · Developer docs

Performance, caching, deployment and go-live

How Core dna caches pages, what makes a render fast, how code reaches a site and what stays behind, the go-live checklist, and running a site once it is live. For developers, leads and site operators who already build pages in a theme repository.

L2–L3
Unit 05 · Go-live

SEO continuity

A migration should not cost the client their search traffic. One hostname, canonical URLs, structured data, robots and the generated sitemap on launch day, crawl budget on a large site, and the checks that prove nothing was lost.

Who this is for. The developer responsible for a site's search visibility through a launch or a migration. Afterwards you can set each signal search engines read, confirm the sitemap is being served, and show with before-and-after data that the move kept what the old site had.

Search engines judge a moved site by whether they can find, for every page they knew, the same content at a new address that says it is the same page. The redirect map does most of that work (Redirect mapping). The rest is the few signals each page sends about itself, and they are easy to get wrong in the rush of a launch.

One hostname

Every page should be reachable at exactly one hostname, the primary one, over HTTPS. A site that answers on both example.com and www.example.com splits its ranking between two copies. On Core dna each hostname attached to an environment serves that environment. Ask Core dna to redirect the others to the primary hostname in front of the platform, or redirect from the base template:

Template code templates/includes/frontend/base-template.html
{if !$_currentSite->isPrimaryHostname() && $_currentSite->getPrimaryHostname()}
  {$target = 'https://'|cat:$_currentSite->getPrimaryHostname()|cat:$_request->getPath()}
  {if $_request->getQueryString()}{$target = $target|cat:'?'|cat:$_request->getQueryString()}{/if}
  {$_response->redirect($target, 301)}
{/if}
{% if not _currentSite.isPrimaryHostname() and _currentSite.getPrimaryHostname() %}
  {% set query = _request.getQueryString() %}
  {% do _response.redirect('https://' ~ _currentSite.getPrimaryHostname() ~ _request.getPath() ~ (query ? '?' ~ query : ''), 301) %}
{% endif %}

Put it first in the base template, before anything renders: redirect() stops the render and answers with the redirect. Only a 200 is stored in the page cache, so the redirect itself is never stored, but a page stored under the other hostname before the redirect existed still is: clear the cache when you release it. The test uses the environment's own primary hostname, so it behaves the same on staging.

Canonical URLs and structured data

  • Every page names its canonical URL on the primary hostname: the record's SEO canonical URL where an editor set one, otherwise its own path. Filtered and paginated variants of a listing point at the unfiltered listing. The template pattern is on The edges of a page.
  • Structured data carries over. Whatever the old site declared (organisation, products with prices, articles, breadcrumbs), the new site declares the same types for the same pages. Carrying product data over keeps the rich results it had earned.
  • Titles and descriptions carry over for the pages that rank, unless rewriting them is a deliberate decision.

Robots and the sitemap on launch day

  • robots.txt is a file in the theme repository, served from the site root like any other static file. On launch day it must allow crawling and name the sitemap. Check too that the noindex used on staging is not on production (two legitimate uses), and that no record's SEO robots setting blocks indexing by mistake.
  • /sitemap.xml is generated by the platform from published pages, posts, books, products and FAQ, each type switched on or off by its module's "generate in sitemap" setting (pages on by default, books off). A record whose SEO robots setting says not to index is left out, and a record with a canonical URL is listed at that URL, or left out when it points at another site.
  • The file is rebuilt every hour for each site's primary environment and served from a file in the environment's folder. When the file is missing or more than an hour old, the request answers 202 with an empty body and queues a rebuild. So right after launch, request it until it answers 200 with content, and only then submit it to search engines.
HTML robots.txt
User-agent: *
Allow: /

Sitemap: https://www.example.com/sitemap.xml

Crawl budget on a large migration

A search engine crawls a site at a limited rate. On a site of tens of thousands of URLs, a migration asks it to recrawl everything, and wasted requests delay the pages that matter:

  • No redirect chains. Every old URL goes straight to its final address; the redirect test checks for this.
  • Internal links to new URLs. Links in the content that still point at old URLs make every visit and every crawl go through a redirect. Replace them in the content.
  • A sitemap of canonical 200 pages only: no redirects, no filtered variants.
  • No endless URL spaces. Facet combinations, calendars and sort orders can produce millions of URLs. Point their canonical at the unfiltered page and keep them out of the sitemap.

Before-and-after checks

  1. Before: crawl the old site and save, for each URL, its status, title, description, canonical and structured data types. Export the top queries and landing pages from the search console.
  2. On launch day: crawl the new site from the same list of old URLs, following redirects, and compare the saved fields for each final page.
  3. For eight weeks after: each week, watch indexed pages, crawl errors and the positions of the top queries in the search console. A dip in the first weeks is normal; a page count that keeps falling, or a rise in not-found errors, means redirects are missing.
Go deeper

Was this page helpful?

Your answer goes to the docs team.