Mirror sites

Mirror sites is the setup of one or several backup copies of the site on other domains and/or servers that can take traffic when the main one is unavailable (failure, blocking, overload). We work out the content synchronization scheme, traffic switching, and correct SEO wiring. Honestly about the purpose, this is key: a mirror solves the task of AVAILABILITY and resilience (there is a backup address), NOT security: if the site has a vulnerability — it is copied into the mirror too, it can be hacked as well. This is about 'the site is available', not 'the site is protected'. Honestly about dynamics, this matters: for static sites a mirror is made simply, while for dynamic ones with a database and user accounts honest synchronization is complex — data on the mirror may lag or it is made in 'read-only' mode. We will realistically assess your architecture and say what is feasible. Honestly about SEO: identical content on several domains without proper setup (canonical/robots/switching) creates duplicates and harms ranking — we account for this. Honestly about costs: additional domains and hosting for mirrors are paid separately and on an ongoing basis. Honestly about the boundary: a mirror is not a CDN (acceleration and load distribution) and not a full fault-tolerant cluster; it is a backup site. Honestly about access: access to the servers/DNS is needed. An important boundary: mirrors (availability), while backup+DR (770) and anti-DDoS are separate measures. Picture this: instead of 'the main site is down or blocked — and that's it, you are unavailable' — the mirror picks up the traffic. The base price starts from 20,000 ₽ (excluding the cost of extra domains/hosting); it depends on the site type and the number of mirrors.

• The main site is down or blocked — and you are completely unavailable.
• No backup site in case of failure or blocking.
• A mirror was made hastily — content duplicates harm SEO.
• It is unclear how to synchronize a dynamic site with a database.

• Analysis of the architecture (static/dynamic/DB) and feasibility of mirrors
• Setting up backup copies on other domains/servers
• A content synchronization scheme (with an honest assessment for dynamics)
• Traffic switching when the main one is unavailable
• Correct SEO wiring (canonical/robots — no duplicates)
• Indicating boundaries (availability, not protection; not a CDN)
• Switching verification
• Handover and review with you

• There is a backup site on failure/blocking of the main one
• Traffic is picked up by the mirror
• SEO does not suffer from duplicates (correct wiring)
• Increased availability (protection and DR — separate)

• We analyze the architecture and feasibility of synchronization; collect access
• We set up mirrors, synchronization, switching and SEO wiring
• We verify switching, review boundaries and costs with you

• Will a mirror protect against hacking?

  No, this is about availability, not protection. If the site has a vulnerability — it is copied into the mirror too, it can be hacked as well. A mirror solves the task of 'the site is available even if the main one is down or blocked', while protection against hacking is separate measures (validation, WAF, fixing vulnerabilities).

• We have a dynamic site with a database and accounts — will a mirror work?

  It is harder than for static, and we are honest about it. Full real-time synchronization of the database and user accounts is a non-trivial and expensive task; often a mirror is made with data lag or in 'read-only' mode as a backup storefront. We will realistically assess your architecture and say what is feasible and for what money.

• Won't SEO suffer from identical content?

  It can suffer if done hastily: identical content on several domains without proper setup creates duplicates and harms ranking. So we set up the SEO wiring (canonical/robots/switching logic) so that the mirror is a backup, not a competitor to the main site in search.