/resources/sitecore-wordpress-migration/
What We Do
Digital Platform MigrationsKey SolutionsManaged ServicesStaffing SolutionsIndustriesProducts
OnePress
Unify multiple brands on one governed WordPress platform.
Design & UI/UX
Gutenberg-native UX, UI, and design systems for visitors and editors.
WordPress Modernization
Modernize WordPress for better performance, architecture, and AI readiness.
WordPress as a DXP
WordPress as a composable DXP when monolithic systems no longer cut it.
Headless WordPress
Omnichannel content delivery without sacrificing marketing autonomy.
Frappe/ERPNext
Build scalable ERP and custom applications, from implementation to ongoing support.
Discovery
Strategic consultancy & project roadmap
Growth Services
On demand development & consultation
Site Maintenance
Annual maintenance. Done for you
QE Services
Testing across SDLC for assured quality
Hosting Migration
Move to a performant hosting with zero downtime
WooCommerce
Enterprise commerce delivered without lock-in
AI
Unlock real use cases and integrations
All Services
A suite of services for any need
Technology STACK
eCommerce
Scale your e-commerce with WooCommerce, integrations, and custom extensions for growth.
EasyEngine
Server management tool that makes using WordPress on Nginx easy.
Web Auditor
Performance Audit & Insights for your Website.
rtMedia
A complete media management plugin for WordPress.
Resources
About Us
CLEAR
Resources Sitecore to WordPress migration guide: What enterprise teams need to know
Topics
On this page
TL;DR
Why enterprises leave Sitecore
The move to XM Cloud requires another major rebuild
The DXP capabilities never became part of daily work
Specialist dependency raises operating costs
Sitecore vs WordPress at a glance
Plan the migration before choosing tools
Understand the migration risks
Audit the existing Sitecore setup
Document the Sitecore stack
List third-party integrations
Audit every Sitecore function/feature you’re using
Trace workflows from start to finish
Audit your content
Map users, roles, and permissions
Review media and DAM requirements
Establish the SEO and performance baseline
Evaluate your WordPress architecture options
Choose the right hosting for your WordPress site
Set up the migration environments
Development
Staging
Live
Secure your Sitecore data
Migrate the Sitecore frontend to WordPress
How the frontend build runs
Migrate the Sitecore backend to WordPress
Migrate Sitecore content to WordPress
Sitecore Content Serialization
Sitecore PowerShell Extensions (SPE)
RESTful Services
Data mapping
Import methods
Preserve SEO equity
Set up redirects
Migrate SEO metadata
Take care of the technical SEO
Run post-migration QA
Validate content
Check the design
Review the media library
Run functional testing
Test performance
Check security
Validate SEO
Test analytics and tracking
Sitecore to WordPress post-migration considerations
Evaluate alignment with migration goals
Benchmark performance metrics
Gather feedback from stakeholders
Assess SEO impact
How moving to WordPress looks at scale
Use the migration to build an AI-ready platform
Get the 20-hour free discovery
Frequently asked questions
How long does a Sitecore to WordPress migration take?
Will we lose SEO rankings?
Can WordPress match Sitecore's personalisation capabilities?
What happens to our Sitecore content model?
Is WordPress secure enough to replace Sitecore?
How much does a Sitecore to WordPress migration cost?
Can our team maintain WordPress after migration?
Is Sitecore XM Cloud really a replatform or just an upgrade?
Last updated on Sep 14, 2026
Sitecore to WordPress migration guide: What enterprise teams need to know
The Sitecore XM Cloud quote has arrived. Your team may call it an upgrade, but the scope looks closer to a replatform.
Sitecore’s own migration guidance supports that assessment. It describes the move from Sitecore XP to XM Cloud, now part of the SitecoreAI product family, as a significant change in how teams develop, manage, and deliver digital experiences. However, XM Cloud isn’t Sitecore XP moved to the cloud. It uses a SaaS, headless-first architecture with a separate rendering application and a new SDK layer.
If you have to replatform anyway, this is an opportunity to evaluate whether you want to rebuild inside the Sitecore ecosystem or move to infrastructure you control.
This Sitecore to WordPress migration guide walks you through that second path. It explains the business case, costs, planning, architecture, hosting, content, SEO, testing, launch, and post-migration operations.
rtCamp has completed 500+ enterprise WordPress engagements, including migrations from AEM, Kentico, Drupal, and enterprise CMSs. We help companies leave proprietary platforms with a clear plan for what happens to their content, code, and integrations. We are also a WordPress VIP Gold Agency Partner, SOC 2 Type II compliant, and ISO 27001 certified.
TL;DR
- The XM Cloud quote on your desk is the reason this conversation is happening now. Sitecore XP runs the site inside one .NET application; XM Cloud pulls the frontend out into a separate Next.js app that talks to Sitecore over an API. Sitecore’s own docs call it a major architectural change.
- Whichever direction you pick, the front end gets rebuilt. Existing MVC renderings and SXA components don’t come across, .NET developers pick up React, and every integration reconnects to the new API layer. That’s true for XM Cloud and it’s true for WordPress.
- The Sitecore bill, once everything is counted, sits at $170K–$450K a year — licensing, hosting, maintenance, upgrades. Add Sitecore Personalize and the number climbs by another seven figures at production scale. Over five years, most enterprises are looking at $700K to $1.5M for a platform where they actively use maybe 40% of what they’re paying for.
- Sitecore probably still earns its place if CDP, Personalize, and Content Hub are all doing real work in your organization, if your headless setup is already humming, or if you’re mid-transformation and can’t absorb another platform decision this year.
- The AI question changes the calculus. WordPress 7.0 ships with a native AI layer, rtCamp built three of the connectors (OpenRouter, LM Studio, Universal OpenAI), and personalization, LLM discoverability, and AI-assisted editorial all run on infrastructure you already own. On Sitecore, most of that arrives as another line item.
- SEO holds when someone actually maps it. Sitecore’s item tree and template inheritance produce URL patterns that a generic redirect plugin won’t catch. Every indexed URL gets a destination before DNS moves, redirect chains get validated, and staging runs a full crawl against the baseline. Cox Automotive consolidated 8 brands onto WordPress with Core Web Vitals up 2×.
- Straightforward single-site migrations run 3–5 months. Multi-brand, multi-language, or content-heavy work runs 5–9.
Why enterprises leave Sitecore
Sitecore was built for large organisations with complex digital experience requirements. But most companies use it to publish pages. And pay for the rest anyway.
The Sitecore license cost is only one part of the bill. It also requires specialist developers, regular upgrades, infrastructure, and ongoing partner support.
We call the total effect the Platform Tax. It’s the cumulative cost of staying on a platform that no longer fits how the organisation works: license fees + upgrade cost + consultant dependency + opportunity cost of every delayed roadmap item. Applied to Sitecore, it looks something like this.
Sitecore can cost $170,000–$450,000 a year to run: $60,000–$150,000 for licensing, $40,000–$120,000 for hosting, and $70,000–$180,000 for maintenance and upgrades. Over five years, the Sitecore total cost of ownership can reach $700,000–$1.5 million.
Want figures based on your actual Sitecore contract? Use our DXP TCO Calculator to see what your Sitecore platform costs against a comparable WordPress setup →
The move to XM Cloud requires another major rebuild
XM Cloud reduces the infrastructure workload associated with Sitecore XP, but an existing XP implementation cannot simply be moved as is.
Sitecore XP renders pages within the .NET application. XM Cloud separates content management from the presentation layer, so the frontend becomes its own application, built with Next.js and connected to Sitecore through APIs. Existing MVC renderings and other platform-specific customisations therefore need to be rebuilt or replaced. Integrations must also be adapted to the new architecture. Sitecore provides tools for migrating content and media, but moving the data is only one part of the project.
The DXP capabilities never became part of daily work
Sitecore is often selected for personalisation and customer-data capabilities. Years later, the marketing team uses Sitecore to create and publish web pages. As a result, the organisation pays for the broader product while relying on a small part of it.
Specialist dependency raises operating costs
A mature Sitecore implementation depends on a small group of certified developers. That creates a labour premium and key-person risk.
Routine work can move slowly when editors need development support to adjust a component or change how structured content appears. The cost then extends beyond engineering rates. Campaigns wait, experiments get postponed, and the product roadmap fills with CMS maintenance.
The decision to leave should come from your actual architecture, however. Staying may be the better option when:
- Your organisation uses Sitecore CDP, Personalize, Content Hub, and related products.
- Your existing headless frontend is performing well and moving it would create little operational benefit.
- Your team has strong Sitecore expertise and no shortage of development capacity.
- A migration would interrupt a more important transformation already underway.
- Regulatory or contractual dependencies make the current environment difficult to change.
For everyone else, the XM Cloud project creates a natural point to compare the cost of staying with the cost of leaving.
Sitecore vs WordPress at a glance
If you are on Sitecore, you know why you chose it. That decision wasn’t wrong, but does the same reasoning still hold?
Sitecore’s DAM is mature, and its customer-data products connect to the CMS through a single vendor relationship. That coherence has a cost: Sitecore sets the pricing, the upgrade schedule, and the product roadmap. When Sitecore decides XP customers need to move to XM Cloud, the decision has already been made for them.
WordPress is open-source. The organisation owns the codebase, chooses the infrastructure, and adds or removes tools without renegotiating a contract. At enterprise scale, it can support heavy traffic and large brand portfolios. For example, Penske Media Corporation, which owns Rolling Stone, Variety, and Billboard, handles hundreds of millions of monthly pageviews on WordPress VIP. One of our clients, Cox Automotive, runs eight brands on a shared WordPress codebase, while Al Jazeera uses WordPress as its global editorial platform.
One more thing to add: Sitecore Personalize is a separately licensed product. WordPress personalisation runs on infrastructure the organisation already owns. rtCamp delivers it as one of the 5 AI Dimensions, a set of AI capabilities built into every migration engagement, with no additional licensing.
The main differences are easier to see side by side.
AreaSitecoreWordPress****Platform modelProprietary DXP sold through enterprise contractsOpen-source software with no licence feeArchitectureSitecore XP uses an integrated .NET architecture; XM Cloud uses a SaaS, headless modelCan run as a conventional CMS or headless platformEditorial workMature editing tools, though custom layouts may depend on Sitecore developersGutenberg blocks and patterns let editors build pages from approved componentsContent modellingTemplates, fields, items, and taxonomiesCustom post types, fields, blocks, and taxonomiesMultisiteNative support for multisite and multilingual implementationsWordPress Multisite supports many sites on a shared codebasePersonalizationBuilt-in rules for region, referrer, UTM, landing page, and visitor status. Advanced use requires Sitecore Personalize. The same basic rules can be added through plugins or CDN. Advanced tools can be chosen independently.HostingCustomer-managed infrastructure for XP; Sitecore-managed SaaS for XM CloudChoice of managed enterprise hosting or customer-controlled infrastructureProduct roadmapControlled by SitecoreControlled by the organisationSpecialist availabilitySmaller pool of Sitecore developersBroader WordPress and PHP talent pool
Plan the migration before choosing tools
A Sitecore migration should begin with outcomes. Define what the organisation expects to improve and how you will measure it.
Goal****MeasurementReduce platform costCompare annual platform and support spend before and after migration.Increase publishing speedMeasure time from approved draft to publication.Reduce developer dependencyTrack CMS-related editorial tickets per month.Preserve search trafficCompare organic sessions and rankings before launch and at 30, 60, and 90 days.Improve performanceCompare Core Web Vitals by page type.Simplify multisite managementMeasure shared code and component reuse across brands.Improve release reliabilityTrack deployment frequency, failed releases, and rollback rate.
Then decide whether the project will retain the existing design or include a redesign. That choice affects component scope, content transformation, QA, training, and timeline. A late decision can force the team to rebuild completed work.
With that agreed, you can scope the enterprise CMS migration and test the approach before starting the full build. At rtCamp, the work runs through the following stages:
Audit → We map your Sitecore architecture, content, integrations, and URL structure. The output is a phased migration roadmap with confirmed risks and budget. This stage is 20 hours, free, and can start in 7 days.
Pilot → A contained first delivery. We migrate one section of the site end to end, validating the approach prior to the full build.
Phased Build → Frontend, backend, and content migration run in parallel. We build on a staging environment while the live site stays live throughout.
Enablement → We deliver editorial documentation and role-specific training before launch, so the team publishes independently from day one.
Hypercare → 30 days of dedicated monitoring, issue resolution, and performance optimisation after go-live. Included as standard.
Evolution → Ongoing maintenance, managed growth, or staff augmentation. The average rtCamp client engagement runs six years.
Understand the migration risks
Migration problems often begin with dependencies the team did not know existed. It might be an undocumented integration or a custom field used by one region. When these dependencies surface early, they are cheaper to deal with.
What can go wrongHow we reduce itIncomplete discovery❗Custom code, workflows, or integrations appear late and change the scope.✔️Audit the architecture, configuration, content, and connected systems before confirming the roadmap.Poor content mapping❗Sitecore items become generic WordPress pages, making structured content difficult to reuse or manage.✔️Define the WordPress content model first, then test it on a representative section.SEO loss❗URLs change, redirects fail, or metadata and language signals disappear.✔️Crawl the existing site, map every URL, and compare staging against the SEO baseline.Long content freezes❗A one-time export leaves editors unable to publish while the new platform catches up.✔️Migrate in repeatable batches and use delta migrations for content changed after the first run.Integration failures❗Forms appear to work but leads never reach the CRM, or analytics records the wrong events.✔️Test the full journey from the visitor action to the final system.No rollback path❗Sitecore is decommissioned too early, or the team cannot restore the WordPress release after cutover.✔️Rehearse the launch, define rollback triggers, and keep Sitecore available until WordPress is stable.
The next step is to trace how Sitecore works today, including things stakeholders assume happen somewhere else.
Audit the existing Sitecore setup
Sitecore implementations collect years of custom code and integrations. Before moving any of it, find out what you are going to move.
Document the Sitecore stack
Start with the platform itself. Record the Sitecore version, deployment model, hosting, search provider, databases, CDN, caching, multisite setup, and languages. Then record the Sitecore products in use. Here’s a quick list of Sitecore’s solutions for reference:
- XM Cloud. Alternatively, you may be using Sitecore’s other CMS solutions like Sitecore Content Hub One or its original CMS solution, Sitecore Experience Manager.
- Search → Sitecore’s search and discovery solution.
- CDP → Sitecore’s customer data management solution.
- Personalize → Sitecore’s personalization and testing solution.
- Content Hub → Sitecore’s DAM solution.
- Connect → Sitecore’s integration solution.
Once you have the list, find a WordPress alternative for each product in use. If you are running Sitecore Personalize, for example, you need to decide what handles personalisation on WordPress. It might be Logic Hop, HubSpot, or a custom build.
Sitecore solution****In use?****WordPress equivalentCMS☐ Sitecore Experience Manager
☐ Content Hub One
☐ Sitecore XM CloudWordPress CMSSearch☐ Yes / ☐ NoAlgolia, SearchWP, customCDP☐ Yes / ☐ NoSegment, Twilio, customPersonalize☐ Yes / ☐ NoLogic Hop, Uberflip, HubSpot, customContent Hub (DAM)☐ Yes / ☐ NoGoDAM, Cloudinary, customConnect☐ Yes / ☐ NoZapier, Make, customSend / other apps☐ Yes / ☐ NoList alternatives
List third-party integrations
Document every external system connected to Sitecore. A typical setup may use Salesforce for sales, HubSpot for marketing automation, Slack for collaboration, Google Analytics or Parse.ly for reporting, and Cloudflare for performance.
For each integration, record what it does today and how it will connect to WordPress. For example, rtCamp developed the WordPress VIP for Salesforce integration to send WordPress data to Salesforce, which won the “Top Partner Innovator” award.
Note: List any other third-party integrations that you lack in your current setup and need to build on your new WordPress stack.
Audit every Sitecore function/feature you’re using
Some Sitecore features have a direct WordPress equivalent. Others require a plugin, external service, or custom build. Sitecore forms, for example, could move to Gravity Forms or a custom solution connected to your CRM. List every built-in and custom function your team uses, then record how it will be handled in WordPress.
FeatureAvailability in WordPressMigration strategyVisual Editor (WYSIWYG)✅ Built-in (Gutenberg)Direct mapping with frontendForms🧩 Via pluginsPlugins: Gravity Forms, WPForms, or a Custom solution.Co-editing🧩 Via pluginsPlugins: Google Docs integration, or a custom solution.Other custom featuresResearch their availabilityBuild a strategy
Keep in mind that this is an initial mapping exercise. Final tool choices come after the requirements are clear.
Trace workflows from start to finish
Your CMS sits at the intersection of your business processes, like sales, marketing, service, and others. Before migration, map every automated workflow that runs through the platform. Let’s take email automation as an example.
A user fills out a form on the Sitecore site, the submission goes to Sitecore Send, and an automated response goes back to the user. That entire sequence needs to be rebuilt in WordPress, usually with a form plugin like Gravity Forms connected to HubSpot.
Build a table to list all your existing Sitecore workflows or automations and how you’ll move them over to WordPress. It might look something like this:
WorkflowCurrent process in SitecoreWordPress migration planEmail automationForm → Sitecore Send → Automated responseGravity Forms + HubSpotWorkflow #2……
Audit your content
Count and classify everything stored in Sitecore. Preserve relationships between items, fields, media, languages, and reusable components. Also, flag any obsolete content that won’t need to be transferred to your new WordPress site.
These would be:
- Items: your Sitecore website’s pages, like Homepage, About, Contact, service pages, landing pages, and personalised pages.
- Custom templates: all the posts published on your Sitecore website.
- Media: images, videos, audio files, and documents that you might have uploaded to your Sitecore CMS/DAM.
- Custom content types: any specialized content types created for specific needs, like portfolios, testimonials, and events.
- Taxonomies: your Sitecore setup’s categories and tags that you use to organize your content.
- User data: all the information and settings associated with user accounts on your current Sitecore setup.
- Comments: any user-generated content on your posts and pages.
- Item fields: metadata attached to content, like author, publish date, SEO descriptions, OG tags.
- Forms: contact forms, surveys, and any associated submission data.
- Components/renderings: reusable content elements placed in sidebars, footers, and page regions.
Map users, roles, and permissions
Document all roles in the current Sitecore setup, their permissions, and what they can access. The goal is to map each one to a WordPress equivalent before migration begins. For example, a Sitecore Admin maps directly to the WordPress Administrator role with no changes needed. Other roles don’t transfer as cleanly.
Review media and DAM requirements
At this step, you have to understand where your media files live today, and where they will live in WordPress.
If your organisation uses Sitecore Content Hub, the migration needs a decision on what replaces it. There are three paths:
- Use the WordPress media library as-is. It covers basic upload, organisation, and retrieval. Enough for most standard use cases.
- Enhance the WordPress media library with custom code. With development work, it can handle file naming conventions, auto-resizing, improved search, and access controls without a third-party subscription.
- Add a dedicated DAM. For larger asset libraries, rtCamp built GoDAM, a DAM solution for WordPress that covers uploading, organising, and searching media files at scale.
Use this table to document your current DAM usage and if the WordPress media library, with custom enhancements, can meet your needs:
FeaturesWordPress defaultPotential enhancementsAdvanced organization✅ Categories & TagsCustom taxonomies, metadata fieldsCustom metadata❌ Not supportedCustom fields for copyright, usage rights, etc.Enhanced search✅ BasicCustom search filters using metadata, faceted searchAutomated workflows❌ NoneAuto-resizing, format conversion, etc.User permissions✅ BasicGranular control over files and actionsVersion Control✅ BasicEnhanced versioning with historyBulk Actions✅ BasicAdvanced bulk editing and downloadsAnalytics & reporting❌ NoneCustom analytics and reporting toolsAccess control✅ Tied to user rolesPermission controls by asset or categoryAsset previews & thumbnails✅ BasicEnhanced preview options for various file types
Establish the SEO and performance baseline
Finally, audit your SEO. It spans five areas.
- Site structure. Crawl the live site and record its structure, navigation, and breadcrumbs. If a sitemap doesn’t exist, generate one using Sitecore PowerShell or a third-party tool.
- URL inventory. Map every indexed URL to its planned WordPress destination and flag which ones need a redirect.
**Page title / AssetCurrent Sitecore URLNew WordPress URL (Planned)****Redirect needed?**Homepage//❌ NoAbout Us/about-us/about✅ YesContact Page/contact-us/contact✅ YesPrivacy Policy/privacy-policy/privacy-policy❌ NoBlog posts/content/blog/article-title/blog/article-title✅ YesService pages/content/service/abc/service/abc✅ Yes
Note: Maintain a spreadsheet to track all your pages and posts, including their backlink data.
- Content performance. Pull keyword rankings and organic traffic data from Google Search Console and Analytics. Note what ranks well and pages that can be dropped.
- Performance benchmarks. Run key pages through Google PageSpeed Insights and record the scores. Test mobile friendliness, server response time, and crawlability using Screaming Frog or Google Search Console. These numbers become the baseline for post-migration comparison.
- SEO metadata and schema. Export all meta titles, descriptions, alt text, canonical tags, OG tags, and schema markup. Technically, your schema markup/structured data is part of SEO metadata, and a single plugin can take care of importing both on WordPress.
rtCamp’s 20-hour free discovery covers everything we’ve discussed here. We’ll go through your current setup and show how to migrate from Sitecore to WordPress before you sign a contract.
Evaluate your WordPress architecture options
Migration is a good time to decide if you want to replicate the current Sitecore architecture or change it. Sitecore runs in three modes:
- traditional (coupled frontend and backend),
- headless (content delivered via API to a separate frontend), and
- hybrid (both models running in parallel).
WordPress supports all three, and switching between them later does not require a replatform.
Traditional WordPress is the fastest path to lower costs and editorial independence. The frontend and backend are coupled, the plugin ecosystem is large, and content teams work without developer involvement for routine publishing.
Headless WordPress uses WordPress as the content backend and a separate framework, Next.js, for example, on the frontend. Content teams work in the familiar WordPress admin. Development teams have full control over the frontend. This approach suits organisations already running API infrastructure or serving content to multiple channels, but it adds frontend engineering overhead.
Hybrid WordPress runs the main site on traditional WordPress while using its APIs to power other applications, like a mobile app or a marketing microsite, for instance.
For most Sitecore teams, traditional WordPress is the right starting point. It delivers editorial independence immediately and costs less to run. Headless or hybrid architecture makes sense when the organisation has a clear multi-channel requirement and the engineering capacity to support it.
Confirm the target architecture before the build starts. Everything else, like hosting, frontend tooling, development scope, follows from this one decision.
You can read more about how Sitecore and WordPress compare in their approach to headless architecture in our Sitecore vs WordPress comparison.
Choose the right hosting for your WordPress site
WordPress gives you two main hosting options: managed hosting or infrastructure your team manages itself.
For enterprise sites, managed WordPress hosting is the right default. WordPress VIP handles security, scalability, backups, performance, and updates. It also comes with direct support access when something needs attention quickly.
Self-hosted WordPress gives more control and lower direct cost. It works well when the internal team has expertise to manage server configuration, security patching, and scaling. Without that, the overhead lands on people who have other things to do.
Set up the migration environments
To run a Sitecore to WordPress migration, you need to configure three separate environments: development, staging, and live.
Development
It’s the local or cloud-based environment where the initial migration work happens. Frontend developers build the theme, backend devs work on the plugin skeleton, and migration engineers handle the migration plugin if one is needed. At rtCamp, this runs on a local development environment alongside GitHub. Learn more about how we set it up here.
Staging
This environment mirrors your actual production setup. Most WordPress hosting providers offer staging environments (either as part of hosting plans or at additional costs). If the project runs on WordPress VIP, code reviews also happen here, adding another layer of quality assurance.
When you use GitHub to write your code, it’s easy to push it to a staging and later to a live environment too. GitHub also allows for continuous integration of code as your developers write it.
Live
The live environment is your final production setup. When everything is confirmed in staging, the code is pushed live via GitHub. The Sitecore to WordPress migration completes when the DNS switches and the live environment takes over.
Secure your Sitecore data
Every migration team thinks it won’t happen to them, but migrations do go wrong. That’s why it’s important to have a tested backup in place when it does.
A full Sitecore backup usually covers:
- Content: All published pages, blog posts, articles, and product descriptions.
- Media files: All images, videos, PDFs, and audio files.
- User profiles: All user accounts, roles, and their associated permissions.
- SEO metadata: Page titles, meta descriptions, keywords, and image alt tags.
- Analytics data: User engagement and analytics information.
- Configurations: Settings related to any third-party integrations.
However, different Sitecore solutions approach backups differently. With a Sitecore XM Cloud, you can’t take a complete backup on your end. Why?
Because Sitecore XM Cloud is a managed service with Sitecore handling the entire instance. For example, to back up customer profiles or user data through database or file system backups, you’ll need to contact the Sitecore support team for help. With media items, you’d use a Sitecore PowerShell script. And so on.
Here are some Sitecore backup methods at a glance:
Data typeTypical itemsBackup methodContent itemsPages, blog posts, articles, product descriptions, etc.Sitecore Serialization: A collection of export tools for your content. Team support may be needed depending on the method.Media assetsImages, videos, PDFs, and audio files.Media Library Export or a custom PowerShell script. Can often be done independently.SEO metadataPage titles, meta descriptions, keywords, and alt tags.Sitecore PowerShell script: The most common method to export this data.User dataUser profiles, roles, and permissions.API transfer: This requires assistance from the Sitecore support team or a developer.
After you take a backup, test it. Confirm it is complete and functional, then store it in encrypted cloud storage with at least one copy offsite.
When you are finished with what we’ve described above, you can move to the actual migration process. We’ll start with the frontend, then move to the backend and content.
Migrate the Sitecore frontend to WordPress
As it usually goes, first, you need to evaluate the current design and define how it can be recreated in WordPress.
This audit focuses on three areas: the theme, the templates, and the components.
- The theme
If you want to retain your existing design, the best way is to create a custom WordPress theme. In most cases, a custom WordPress theme can replicate the exact look of your existing Sitecore website’s frontend, down to the pixel.
In case you go with a redesign, again, you can create a WordPress theme from scratch.
- Templates
Chances are you’ve added or customised Sitecore templates for your marketing collateral, like product pages, landing pages, case studies, and more.
With WordPress, you’ll need to recreate these templates using WordPress’s custom posts feature. WordPress’s support for custom posts combined with the Gutenberg editor gives you lots of design possibilities inside the CMS.
- Components
Sitecore components, like testimonials, pull quotes, FAQs, carousels, and pricing tables, become Gutenberg blocks in WordPress. Each component from the discovery audit gets a corresponding block. It’s flexible and reusable across the site.
How the frontend build runs
Now that you know what you need to recreate, it’s time to get to the migration itself. Here’s how we do it:
- Set up the theme skeleton
Start with a bare-bones theme that handles basic templating, typography, and spacing. Build on it from there.
- Create the main navigation, header, and footer
Build out your WordPress site’s primary navigation menu, header, and footer. These give the site its structure. Make the header and footer dynamic so they can be adjusted without code.
- Build Gutenberg blocks for every component
Use the discovery audit as the brief. Each documented Sitecore component gets a corresponding Gutenberg block.
- Assemble predefined layouts
Combine blocks into common page sections: multi-column layouts, CTAs, image grids. Editors use these to build pages without design skills.
- Build core pages and page templates
Construct the homepage, landing pages, and other key pages. Develop reusable templates for page types the team creates regularly.
- Integrate third-party frontend elements
Add CRM forms, video embeds, and social platforms. Style them to match the theme.
And one more thing: any design element added through custom code or third-party widgets, like sliders, timelines, pricing tables, or embedded videos, needs a WordPress equivalent. And this process is largely manual.
Since the frontend is being rebuilt from scratch regardless of whether the design is retained or redesigned, this is also a good time to consider a refresh.
Migrate the Sitecore backend to WordPress
While the frontend team builds the block library, a backend team works in parallel on the platform functionality underneath. During the audit, the team documented everything the current Sitecore setup does. The backend team takes that list and rebuilds each item on WordPress. In practice, that means:
- Plugins → Install existing WordPress plugins to replicate Sitecore features. Where no plugin covers the requirement, build a custom one.
- Content types and taxonomies → Map Sitecore content types to WordPress custom post types. Recreate category and tag structures so content is organised the same way.
- User roles and permissions → Set up WordPress user roles and capabilities to match the Sitecore permission structure.
- DAM → Configure the WordPress media library or a dedicated DAM solution to handle media files.
- Third-party integrations → Reconnect CRMs, marketing automation platforms, and analytics tools to the WordPress stack.
- Workflows → Recreate content creation, approval, and publishing workflows using WordPress native features or plugins.
- SEO configuration → Install and configure an SEO plugin to manage metadata, sitemaps, and canonical tags.
- Analytics → Integrate tools like Google Analytics or other tracking solutions to monitor site performance and user behavior on your WordPress stack.
- Custom post types and fields → Build custom post types and ACF field groups for any specialised content requirements.
Content migration shouldn’t wait either. Once taxonomies are mapped and user roles configured, migration engineers can start transferring that data from Sitecore to WordPress.
Here’s a snapshot of how your Sitecore to WordPress development roadmap can look:
WeekBackend and feature developmentFrontend theme development****MigrationEngineer 1Engineer 2Engineer 1Engineer 21• Plugin skeleton• Plugin listDAM implementation• Theme skeleton• Common templates/sectionsGutenberg blocksMigration plugin base2• Post types• Taxonomies• Global tagmanagement• User roles and capabilities• Global optionsFull-width navigation (Header mega menu)Gutenberg blocks• Taxonomies• User migration3• URL mapping and rewrite rules• Sitemapsredirection• Robots.txt• SEO & Social sharingHeader and footerGutenberg blocksMedia migration4• Editorial workflow• UAT (Self-testing)• Enhancements and fixesGutenberg blocksGutenberg blocks• Content migration• Media migration5Redirection scripts• UAT (Self-testing)• Enhancements and fixesGutenberg blocksGutenberg blocksContent migration6Block page templatesThird-party integrationContent migration7QA: Gutenberg blocksQA: Third-party integration• Content migration• Delta migration script
Next, we move on to content migration, followed by QA and other final checks.
Migrate Sitecore content to WordPress
Content migration moves pages, posts, media assets, user profiles, taxonomies, and metadata from Sitecore to WordPress. No single tool handles all of it, so the work runs as a mix of automated and manual methods.
Automated****ManualStandard content, like blog articles, media assets, and user data, moves through scripts and export tools.Bespoke elements, like the homepage, unique landing pages, and custom layouts, get moved and rebuilt by hand.
Which export path fits depends on the Sitecore product in use (XM, XM Cloud, XP, or Content Hub One) and whether the instance is on-premises or managed, as each has different export options and different compatibility with Sitecore’s bulk-data tools. Our guide for Sitecore to WordPress content migration covers the export routes (Content Serialization, PowerShell Extensions, REST APIs), the Sitecore-to-WordPress data mapping, and the three import methods in full.
Sitecore Content Serialization
One way to extract content from Sitecore is through serialization. It saves Sitecore items and their fields as files that migration scripts can read and convert into WordPress content.
Your Sitecore project may already use:
- TDS (Team Development for Sitecore), a paid toolkit that supports Sitecore .item files and YAML.
- Unicorn, an open-source tool that stores Sitecore items as YAML.
- Sitecore Content Serialization, Sitecore’s own YAML-based tool.
The Sitecore version and existing project setup will determine which option is available. The files still need to be mapped and transformed before they can be imported into WordPress. Content not covered by the serialization setup may need to be extracted through an API or custom script.
Sitecore PowerShell Extensions (SPE)
SPE automates admin tasks and bulk content exports. It can export content in JSON, XML, or CSV, with control over which fields and relationships are included. SPE does not support Sitecore 7.x or below, and your team will need to know PowerShell scripting.
RESTful Services
Sitecore’s REST APIs export data in JSON format. They are designed for individual item access, so bulk retrieval requires custom scripting. Also, you’ll need advanced knowledge about RESTful APIs and integration concepts to get this to work.
There is no single right answer on which option to use. It depends on what version of Sitecore you are running and what the content looks like. Most migrations use a mix.
Data mapping
When you’ve exported your Sitecore content, or sometimes even before exporting (depending on the kinds of scripts you’re using), it’s time to map it to WordPress’s ecosystem.
Here’s a table mapping the common elements from Sitecore to WordPress:
Sitecore****WordPressPagePageArticlePostMedia ItemMedia fileCategoryCategoryTagTagSEO metadataTranslates to the different SEO metadata fields in the SEO plugin you choose.User profileUser profileTemplateThemePage layoutPage templateComponentBlock, widget, or pattern
Import methods
Finally, you can import data to WordPress. Take a look at some ways to do that:
- Via plugin → WP All Import maps exported data to WordPress native elements: posts, pages, custom post types, taxonomies. For complex data structures or content nesting, a custom plugin is more reliable.
- Via scripts → Custom scripts give full control over the data transformation process. Use when content types, taxonomies, or relationships do not map directly to WordPress.
- Via API → WordPress REST API accepts imported content programmatically. APIs combined with custom scripts handle the most complex import requirements.
Preserve SEO equity
By the time you decide to migrate, your sites have likely built up years of search rankings and organic traffic. That does not move on its own. So you need to take certain steps to preserve your SEO rankings:
Set up redirects
Take the URL mapping from the discovery audit to decide what happens to each link. Here are the three scenarios possible:
- The URL stays the same, no redirect needed.
- The URL changes to a new WordPress slug, set up a 301 redirect. For example, yourwebsite.com/content/blog/article-title on Sitecore will become yourwebsite.com/blog/article-title on WordPress.
- The URL moves to a completely different path, custom mapping, handled page by page. For example, yourwebsite.com/content/services/service-abc on Sitecore could become yourwebsite.com/services/service-abc or yourwebsite.com/service-abc (or however you prefer) on WordPress.
Use this table for your URL mapping exercise:
Content assetSitecore URLWP URLRedirect typeActionGeneral site page/about-us/about-usNoneDirect match; maintain URLBlog posts/content/blog/article-title/blog/article-title301 RedirectPattern match for all blog posts. This can be “bulk-mapped” using standard rules.Service pages/content/service/service-abc/service-abc301 RedirectCustom mapping for service pages. This needs to be done on a page-by-page basis.General site page/contact-us/contact301 RedirectAlso custom mapping. Update URL to match new naming.
Migrate SEO metadata
You also need to move your SEO data from your Sitecore instance to the new WordPress stack.
To do so, use one of the export tools we discussed in the content migration section. These might be Sitecore PowerShell scripts, for example.
For importing them to WordPress, consider using a plugin like Yoast.
You can read on how we migrated SEO equity for one of our clients to better understand the process.
Take care of the technical SEO
After the metadata is in place, handle the remaining technical items:
- Compress images to reduce page load times.
- Verify Google Analytics and Tag Manager are firing correctly across all pages.
- Set up caching and CDN for page speed.
- Generate a new XML sitemap via the SEO plugin and submit it to Google Search Console and Bing Webmaster Tools.
Run post-migration QA
The migration is complete. But does it work? Check it before your users do.
Validate content
Confirm all pages, posts, and media assets transferred from Sitecore to WordPress.
Verify migrated content displays correctly on the frontend.
Check that categories, tags, and taxonomies are intact and content is organised as expected.
Check the design
Compare the design against the original Sitecore site.
Test responsive behaviour across different viewport sizes.
Validate dynamic elements, like forms, interactive components, and UX flows.
Review the media library
Confirm all images, videos, and multimedia assets are present.
Verify media files load correctly and are optimised for performance.
Check that file attachments, like PDFs and documents, are accessible.
Run functional testing
Confirm all features and functionalities work as intended.
Test editorial workflows end to end.
Verifying integrations.
Test performance
Run key pages through Google PageSpeed Insights and compare against the pre-migration baseline.
Verify caching is configured the way it should be.
Check general site performance and loading speeds.
Check security
Confirm security best practices are in place, like strong passwords, login restrictions, and two-factor authentication.
Verify security certificates are installed and active.
Make sure WordPress user roles and permissions are correctly mapped from Sitecore.
Validate SEO
Verify all SEO metadata, like title tags, meta descriptions, alt tags, are transferred intact.
Validate URL structures and redirects.
Ensure schema markup is correctly implemented in WordPress.
Test analytics and tracking
Confirm Google Analytics or other tracking tools are set up and capturing data accurately.
Check that goals and conversions carried over from Sitecore.
Validate event tracking, form submissions, clicks, scroll depth.
Sitecore to WordPress post-migration considerations
You began the migration with a set of measurable goals. WordPress is live now, time to test them.
Evaluate alignment with migration goals
Return to the goals set at the start of the migration and check how many are already being met. Some will take longer to show up. For instance, if the primary goal was to reduce costs, it’s unlikely you’ll see the complete financial impact immediately. A more realistic evaluation period is around a year. This timeline will show whether the migration was a smart investment. Rest assured, it will.
Benchmark performance metrics
Rerun the performance tests conducted on the Sitecore site before migration. Use tools like PageSpeed Insights or Web Auditor and compare results against the pre-migration baseline. If there is room to improve, build an optimisation plan.
Gather feedback from stakeholders
Ask each team how the transition has landed in practice.
- Content teams: Is publishing simpler on WordPress than it was on Sitecore?
- Marketing teams: Has reliance on developers decreased? Can they create and launch collateral independently?
- Administrators: How does routine maintenance compare to Sitecore?
Survey end users too. Use the findings to identify what needs further optimisation.
Assess SEO impact
Give the site time before concluding SEO. Search engines need to re-crawl, re-index, and re-evaluate the site after a migration. Rankings and traffic may fluctuate in the first weeks, that is expected. A clearer picture emerges within two to three months.
How moving to WordPress looks at scale
We will be honest with you: we can’t share a published Sitecore WordPress migration case study yet. But we are working on it. For now, we’ll share migrations from platforms with similar enterprise complexity and show what changed after those teams moved to WordPress.
Cox Automotive was running 8 brand sites, each on its own codebase and its own maintenance schedule. Work done for one brand could not be reused anywhere else. Every site was its own project. rtCamp migrated all 8 from AEM and Kentico onto a single WordPress foundation using the OnePress multisite framework. It’s a shared governed core where 70–80% of the codebase is reused across brands, with each brand retaining its own identity. As a result, 103% more engagement, 100% more leads, 2× Core Web Vitals improvement, and a marketing team that publishes on all brands without waiting on engineering.
Dealertrack, part of Cox Automotive, had a familiar problem: a powerful CMS that required a developer for almost everything. Landing pages, content updates, campaign launches, all went through an engineering queue. After the migration to WordPress VIP, that changed. The team got a Gutenberg and Elementor setup built to their design system, and landing page time-to-market was cut by 50%.
See more enterprise migrations we have run and the results they delivered →
Use the migration to build an AI-ready platform
By now it is clear that either way you will need a rebuild. But with WordPress, you get a platform you own outright, and one that is ready for AI. At rtCamp, we build that in through the 5 AI Dimensions, AI capabilities scoped into every migration engagement. Here are the dimensions themselves:
- Content discovery on LLMs (AEO) makes the site’s content findable by ChatGPT, Perplexity, and Claude.
- AI-led editorial brings AI into the day-to-day content workflow. It helps generate drafts, write alt text, suggest taxonomy, and fill metadata.
- AI-led personalisation we’ve already covered. It delivers personalised experiences without paying per contact or per session to a third-party personalisation platform.
- WordPress as an AI-integrated platform connects WordPress to AI systems at the infrastructure level, so the platform can participate in AI workflows the organisation already runs.
- AI-accelerated development uses AI for design, coding, QA, and DevOps to compress timelines and reduce manual effort at every phase of the migration and beyond.
Together, they turn the migration from a platform switch into a foundation for the next few years.
This isn’t a new direction for us. rtCamp developed 3 AI Connectors to WordPress 7.0: OpenRouter, LM Studio, and Universal OpenAI. We know this space because we help build it.
Get the 20-hour free discovery
We’ll map your Sitecore architecture, tell you what needs rebuilding, and help you put together the internal case.
Book your free discovery session
Frequently asked questions
How long does a Sitecore to WordPress migration take?
Scope is the main driver here. A single site with moderate rendering complexity is ready in 3–5 months. Add multiple brands, languages, or a large content volume, and that stretches to 5–9 months. Our 20-hour free discovery scopes it for your implementation before you sign a contract.
Will we lose SEO rankings?
Rankings are not lost in migrations. They are lost in migrations that were not planned properly. We map every indexed URL to its WordPress destination before anything moves, validate redirect chains, and run a crawl simulation in staging prior the DNS switch. VinSolutions went through this process and came out with every SEO rank intact and Core Web Vitals up 48%.
Can WordPress match Sitecore’s personalisation capabilities?
For most organisations, yes, and without the licensing bill. Sitecore Personalize is a separately priced product that runs seven figures annually at production scale. On WordPress, personalisation runs on infrastructure you already own. No per-contact fees or separate contract.
What happens to our Sitecore content model?
Your Sitecore content model gets rebuilt. Sitecore Templates become Custom Post Types with ACF Pro field groups. Renderings and SXA components become Gutenberg blocks built to your design system. The decisions made in the content mapping stage determine how your editorial team works on day one and for the years that follow.
Is WordPress secure enough to replace Sitecore?
Yes, when it is built and managed for enterprise use. Organisations such as Penske Media and News UK use WordPress VIP for high-traffic publishing. The platform holds FedRAMP Moderate authorisation and SOC 2 Type I attestation. rtCamp is also SOC 2 Type II compliant and ISO 27001 certified. Plus, every plugin goes through a security review before it touches the codebase.
How much does a Sitecore to WordPress migration cost?
It depends on what you are migrating. The range runs from $50K to $300K+. The 20-hour free discovery gives you a phased budget specific to your setup so you know the number before committing to anything. The biggest cost drivers are integrations and editorial workflow complexity, though.
Can our team maintain WordPress after migration?
Editors can handle everyday publishing and content updates in WordPress without relying on developers. Sitecore teams will still have a few things to relearn, especially if they are used to Experience Editor and Sitecore’s publishing process.
We train editors on the WordPress tools and workflows, and provide role-specific documentation before launch.
Is Sitecore XM Cloud really a replatform or just an upgrade?
Moving to XM Cloud from Sitecore XP is a replatform in everything but name. The Helix MVC architecture gets rewritten in Next.js and JSS, existing components do not transfer, and .NET developers need to retrain on React. Every implementation team that has done it puts the effort and Sitecore XM Cloud migration cost in the same range as a new build.
At that point, the Sitecore alternatives enterprise companies consider start to look more attractive. Moving to WordPress, for example, also requires a rebuild, but you gain ownership of the codebase and more choice over hosting, integrations, and future development.
Credits
Aviral Mittal
Author
Aviral Mittal
Author
Aviral Mittal is the Chief Marketing Officer at rtCamp, where he established and leads the marketing function, building and growing a team of 20+ specialists across content, SEO, design, and growth…
Contributions and Updates: Usama 
Good Work. Good People.
Industry partnerships
Compliance certifications
United States India
© rtCamp Inc. since 2009. All rights reserved.
Terms of Service · Privacy Policy · Trust Center
Company
Solutions
Subscribe to our newsletter and get a few email updates every month.
United States India
© rtCamp Inc. since 2009. All rights reserved.
Terms of Service · Privacy Policy · Trust Center
Cookie Consent
We value your privacy
We use cookies to give you the best possible experience. By clicking “Accept,” you consent to our use of cookies to improve site functionality, analyze usage, and personalize content and communications. Your privacy matters to us, and we are committed to handling your data responsibly and transparently. Please check our Privacy Policy for more details.
Manage PreferencesDon’t AllowAllow All
Why do we use cookies?
×
By clicking "Accept" or "Decline All" at the bottom, you consent to the use of cookies and other tools as described in our Cookie Policy in accordance with your settings and accept our Terms of Service.
Toggle EssentialEssential
Essential cookies enable basic functions and are necessary for the proper function of the website.
Name
Description
Duration
Geolocation Config
This cookie is used to store the consent settings based on the visitor's location.
30 days
Cookie Preferences
This cookie is used to store the user's cookie consent preferences.
30 days
Toggle CloudFlareCloudFlare
CloudFlare provides web performance and security solutions, enhancing site speed and protecting against threats.
Service URL: developers.cloudflare.com (opens in a new window)
Name
Description
Duration
cf_clearance
Whether a CAPTCHA or Javascript challenge has been solved.
session
Toggle CommentsComments
These cookies are needed for adding comments on this website.
Name
Description
Duration
comment_author
Used to track the user across multiple sessions.
Session
comment_author_email
Used to track the user across multiple sessions.
Session
comment_author_url
Used to track the user across multiple sessions.
Session
Toggle GodamGodam
GoDAM" is primarily a specialized WordPress plugin and media management service designed to enhance video hosting, marketing, and asset management directly within the WordPress dashboard.
Service URL: godam.io (opens in a new window)
Name
Description
Duration
user_image
Temporarily stores the path to the user's avatar or profile picture for quick rendering in the website header.
session
user_id
Stores the numerical ID of the logged-in user to maintain session continuity and basic site operations.
session
full_name
Stores the logged-in user's display name to personalize the site interface without needing database queries.
session
system_user
First-party cookie used to store basic application state identifying the current system user role.
session
sid
A generic session ID cookie used to maintain user state and functionality as the visitor navigates through the site.
session
Toggle Google reCAPTCHAGoogle reCAPTCHA
Google reCAPTCHA helps protect websites from spam and abuse by verifying user interactions through challenges.
Name
Description
Duration
_GRECAPTCHA
Google reCAPTCHA sets a necessary cookie (_GRECAPTCHA) when executed for the purpose of providing its risk analysis.
179 days
Toggle Google Tag ManagerGoogle Tag Manager
Google Tag Manager simplifies the management of marketing tags on your website without code changes.
Name
Description
Duration
cookiePreferences
Registers cookie preferences of a user
2 years
td
Registers statistical data on users' behaviour on the website. Used for internal analytics by the website operator.
session
Toggle StatisticsStatistics
Statistics cookies collect information anonymously. This information helps us understand how visitors use our website.
Toggle Factors AIFactors AI
Factors.ai is a B2B account intelligence and marketing analytics platform that helps Go-To-Market (GTM) teams identify anonymous website visitors, track buyer journeys, and measure the ROI of marketing campaigns.
Service URL: www.factors.ai (opens in a new window)
Name
Description
Duration
_fuid
It is sent to capture session details and track user behavior across your website to provide behavioral data and intent signals.
1 Year
Toggle Google AnalyticsGoogle Analytics
Google Analytics is a powerful tool that tracks and analyzes website traffic for informed marketing decisions.
Service URL: policies.google.com (opens in a new window)
Name
Description
Duration
FPGSID
Stores a session or user identifier to track how visitors interact with a website. This helps Google Analytics measure website performance, user engagement, and usage patterns.
Session
FPLC
Used by Google Analytics to link visitor interactions and sessions across multiple related domains.
20 hours
FPID
A server-side Google Analytics cookie used as an alternative user identifier when third-party cookies are restricted.
2 years
_ga
ID used to identify users
2 years
_ga_
ID used to identify users
2 years
Toggle Jetpack StatsJetpack Stats
Jetpack's built-in visitor analytics. It records page views, referring sites, search terms, and outbound link clicks, and also carries the shared visitor-tracking library used by Jetpack Instant Search and WooCommerce Analytics.
Service URL: automattic.com (opens in a new window)
Name
Description
Duration
tk_aip
Stores a list of anonymous visitor IDs so they can be merged into one identity once a visitor is recognized.
Up to 5 years
tk_tc
Used once per page load to work out which cookie domain the Tracks library should use, then removed as soon as it's read back.
Session (deleted immediately after use)
tk_qs
Queues analytics events for Jetpack's Tracks library so none are lost if the page closes before they can be sent.
30 minutes
tk_ai
Stores a randomly-generated anonymous visitor ID so Jetpack's Tracks analytics library can link tracking events to the same visitor.
Session in wp-admin; up to 5 years on the frontend
Toggle Microsoft ClarityMicrosoft Clarity
Clarity is a web analytics service that tracks and reports website traffic.
Service URL: clarity.microsoft.com (opens in a new window)
Name
Description
Duration
CLID
Identifies the first-time Clarity saw this user on any site using Clarity.
12 months
ANONCHK
Indicates whether MUID is transferred to ANID, a cookie used for advertising. Clarity doesn't use ANID and so this is always set to 0.
Session
_clck
Persists the Clarity User ID and preferences, unique to that site is attributed to the same user ID.
12 months
_clsk
Connects multiple page views by a user into a single Clarity session recording.
12 months
Toggle Parse.lyParse.ly
Parse.ly is a content analytics platform that helps publishers optimize audience engagement and content performance.
Name
Description
Duration
_parsely_session
JSON document storing information identifying a browsing session according to Parsely’s proprietary definition
30 minutes
_parsely_visitor
JSON document uniquely identifying a browser and counting its sessions
13 months
cookies.js_dtest
This cookie determines whether the browser accepts cookies.
session
Toggle MarketingMarketing
Marketing cookies are used to follow visitors to websites. The intention is to show ads that are relevant and engaging to the individual user.
Toggle Bing / MicrosoftBing / Microsoft
Bing, powered by Microsoft, is a search engine providing web, image, video, and map search capabilities.
Name
Description
Duration
MR
Used to collect information for analytics purposes.
6 months
ANONCHK
Used to store session ID for a users session to ensure that clicks from adverts on the Bing search engine are verified for reporting purposes and for personalisation
10 minutes
SM
Used by Microsoft in synchronizing the MUID across multiple Microsoft domains to track users for advertising.
session
MUID
Identifies unique web browsers visiting Microsoft sites. These cookies are used for advertising, site analytics, and other operational purposes.
1 year
Toggle DoubleClick/Google MarketingDoubleClick/Google Marketing
A comprehensive digital advertising platform for managing campaigns, optimizing performance, and analyzing audience data.
Name
Description
Duration
IDE
This cookie is used for targeting, analyzing and optimisation of ad campaigns in DoubleClick/Google Marketing Suite
2 years
ar_debug
Store and track conversions
Persistent
Toggle LinkedInLinkedIn
LinkedIn is a professional networking platform for job seekers, employers, and industry connections.
Name
Description
Duration
bscookie
Used by LinkedIn to track the use of embedded services.
1 year
AnalyticsSyncHistory
Used to store information about the time a sync with the lms_analytics cookie took place for users in the Designated Countries
30 days
bcookie
Used by LinkedIn to track the use of embedded services.
1 year
li_sugr
Used to make a probabilistic match of a user's identity outside the Designated Countries
90 days
lidc
Used by the social networking service, LinkedIn, for tracking the use of embedded services.
1 day
UserMatchHistory
Used by LinkedIn Ads to synchronize and match user IDs across different ad networks and data providers.
30 days
Toggle LinkedIn InsightLinkedIn Insight
LinkedIn Insight is a web analytics service that tracks and reports website traffic.
Service URL: www.linkedin.com (opens in a new window)
Name
Description
Duration
li_sugr
Used to make a probabilistic match of a user's identity.
90 days
lidc
Used for routing and session management.
24 hours
Toggle LiveIntentLiveIntent
LiveIntent provides a platform for email advertising and identity-driven marketing solutions.
Name
Description
Duration
_lc2_fpi_js
Companion cookie to _lc2_fpi used by JavaScript to facilitate cross-domain ad tracking and user identification.
1 year
_lc2_fpi
First-party tracking cookie usually associated with LiveRamp to identify users across devices for targeted advertising.
1 Year
_li_ss
Sets a unique ID for the visitor, that allows third party advertisers to target the visitor with relevant advertisement. This pairing service is provided by third party advertisement hubs, which facilitates real-time bidding for advertisers.
1 month
lidid
Collects data on visitors' behaviour and interaction - This is used to make advertisement on the website more relevant. The cookie also allows the website to detect any referrals from other websites.
2 years
Toggle Cookie PolicyCookie Policy
You can find more information in our Privacy Policy.
Allow AllDecline All
Accept