Setup instructions for popular site platforms

Every address change in Yandex — new domain, adding or removing www, moving to HTTPS — comes down to the same three technical requirements. Where they are configured depends on the platform: server files on a self-hosted site, an admin setting on a hosted one.

What has to be configured, whatever the platform

1. The canonical address of the site, so it generates internal links and absolute URLs consistently on the address you intend to keep.
2. Redirects from the old address to the new one, page to page.
3. robots.txt, reachable and consistent on both addresses, with the Sitemap directive updated.

Where each lives

• Self-hosted (Apache, nginx). Redirects in .htaccess or the server configuration; the site address in the application’s own settings. Full control, and the burden of getting the rewrite rules right.
• CMS platforms. Most expose a site address or base URL setting that must be changed as well as the server-level redirect. Changing one without the other produces a site that redirects correctly and then links internally to the old address on every page.
• Hosted builders. Protocol and prefix are usually a switch, and redirects are handled by the platform. The limitation is granularity: many offer only a blanket redirect to the home page, which Yandex explicitly discourages because it strands users and slows indexing of the new site.

The check that catches most mistakes

After configuring, request every variant of the address — with and without www, over HTTP and HTTPS — and confirm that exactly one returns 200 and the rest redirect to it, in a single hop. Then check that robots.txt is reachable on both old and new addresses and that the two files agree. Both checks are available in the console’s server response tool.

Then, and only then

Submit the move through Indexing → Relocate site. The tool records an intention; the configuration is what makes it true, and submitting before the redirects work simply wastes the weeks the change takes to propagate.