Why URL Structure Matters in Bitrix Migration?
Skipping URL mapping during a website migration to Bitrix crashes organic traffic by 50–80% in two weeks. WordPress uses /product/item-name/, OpenCart uses /index.php?route=product/product&product_id=123, Bitrix defaults to /catalog/section/element/. Without a 301 redirect map, search engines index mass 404s. We start every migration with Screaming Frog scanning the old site, then compile a complete redirect map before writing a single line of code. Proper migration requires full URL mapping — every indexed page gets a correspondent.
Over seven years we have completed 50+ projects: landing pages, catalogs with 300,000 products, e‑commerce stores. Typical duration 2–8 weeks. Contact us for a free project estimate within one day.
How Migration Preserves SEO Positions
Losing organic traffic is the biggest fear, and it's justified. Here is how we avoid it.
-
URL mapping 1:1 — where possible, via
CUrlRewriterand infoblock SEF settings we keep the exact structure. When impossible — 301 redirect. Auto‑generation of redirect map: parse Screaming Frog export, match with new element slugs, generate nginx config. Each redirect verified withcurl -Iafter switching. - Transfer of meta tags — title, description, h1 moved into properties
ELEMENT_META_TITLEandELEMENT_META_DESCRIPTION. Canonical via Bitrix SEO component. Duplicates cut: www/non‑www, http/https, sorting parameters. Sitemap: newsitemap.xmlgenerated by Bitrixseomodule, submitted to Search Console immediately after DNS switch. - Speed comparison — Bitrix processes a catalog of 100,000 products 3x faster than OpenCart due to tagged caching and query optimization for
b_catalog_product.
What Data Gets Transferred?
Content — pages, articles, news → information infoblocks. Catalog: categories → sections, products → elements linked to b_catalog_product, properties → infoblock properties or highload directories. Images, reviews, FAQ.
E‑commerce — products with trade offers (SKUs), prices in b_catalog_price (multi‑currency via b_catalog_currency), stock balances b_catalog_store_product, discounts (b_sale_discount), order history (b_sale_order + b_sale_basket).
Users — client base b_user plus custom UF fields. Passwords are hashed differently: WordPress — phpass, OpenCart — SHA1+salt, Drupal — SHA512. We write a custom CUser::LoginByHash with fallback to old algorithm — client enters password once, system rehashes to Bitrix bcrypt.
SEO data — meta tags, alt attributes, URL structure. Main task: preserve every indexed URL or set 301.
Media — images, documents, videos — transferred preserving paths and optimized via CFile::MakeFileArray().
How to Plan a Successful Migration: 5 Key Steps
- Audit — scan with Screaming Frog: all URLs, status codes, meta tags. Analyze DB structure, custom modifications, integrations. Create migration map.
- Architecture design — map content types → infoblocks, fields → properties, directories → highload blocks. Architecture must be convenient for Bitrix administration.
-
Migration scripts — PHP scripts read from old DB (or API), transform and write via Bitrix API (
CIBlockElement::Add,\Bitrix\Sale\Order::create). Re‑run during testing. - Staging — full migration to test server. Verify integrity: product count, properties, URLs, filters.
- Final migration & switching — delta import, DNS switch, monitoring.
Detailed stage timeline
| Stage | Duration | Activities |
|---|---|---|
| Audit | 1–3 days | Full site scan, integration register |
| Architecture | 2–5 days | Infoblock design, field mapping |
| Scripts | 3–10 days | PHP based migration engine |
| Staging | 1–2 days | Full dry run, integrity checks |
| 301 redirects | 1–2 days | Map in .htaccess or nginx.conf |
| Final migration | 1 day | Delta import, DNS switch |
| Post‑migration | 2–4 weeks | Monitor Search Console, fix crawl errors |
| Deliverable | Description |
|---|---|
| Documentation | Redirect map, mapping description, DB schema |
| Access | Admin panel, FTP/SSH, API keys |
| Training | Video tutorials or on‑boarding session |
| Support | 2 weeks post‑migration monitoring, bug fixing |
| Guarantee | Rollback to old site within 48 hours |
Typical Migration Mistakes and How to Avoid Them
Each of these errors has caused loss of positions and clients.
- Loss of URLs without redirects — the most destructive mistake.
/product/123instead of/catalog/item-name.html— without 301 this means mass 404s and traffic collapse. We auto‑generate the map and verify every redirect after switching. - Content duplication — one product accessible with and without www, via HTTP and HTTPS, with GET filter parameters → five URLs instead of one. SEO weight dilutes. Set up canonical, 301 for variants,
robots.txtwithDisallowfor parameters. - Broken images — absolute URLs in content (
src="https://old-site.ru/img/photo.jpg"), quality loss during compression. Replace with relative paths, transfer preserving structure, check HTTP 200 for each file. - Loss of meta tags and microdata — title, description, Schema.org may not transfer. Do full mapping and verify on staging.
- Broken forms and integrations — changed IDs, API keys, webhooks. Compile integration register before start and test each after.
- Mobile version — old
m.site.ru→ responsive Bitrix. Without mobile URL redirect → 404 for mobile users. Include in redirect map.
Timelines and Cost Savings
| Project type | Timeline | Notes |
|---|---|---|
| Informational site (up to 500 pages) | 2–4 weeks | Content + design + redirects |
| E‑commerce store (up to 10,000 products) | 4–8 weeks | Catalog + orders + integrations |
| Large store (100,000+ products) | 2–4 months | Custom scripts + load testing |
Businesses typically save $3,000–$8,000 annually after migration — no old CMS license fees, reduced plugin and hosting costs. Annual hosting savings alone can reach $1,200. Add the affordable licensing cost of 1C‑Bitrix — it pays off quickly.
Contact us for a free migration estimate. We also provide a preliminary calculation within one day — request a consultation with our Bitrix specialists.