/handbook/drupal-to-wordpress-migration-guide/
What We Do
Digital Platform MigrationsKey SolutionsManaged ServicesStaffing SolutionsIndustriesProducts
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 How Enterprises Migrate from Drupal to WordPress
Topics
On this page
- How Enterprises Migrate from Drupal to WordPress
- Business case for migration
- Migration process, timeline & team
- Planning the migration
- Frontend migration
- Content migration
- Backend migration
- Quality assurance
- Site launch
- How can rtCamp help
Why enterprises leave Drupal
1. When an upgrade costs as much as a migration
2. Editorial independence vs developer dependence
3. Even if you upgrade, is it really worth the effort?
WordPress does everything Drupal can, plus marketing autonomy
rtCamp's enterprise migration methodology
The phased delivery model
Discovery and planning
Auditing the existing Drupal stack
Stakeholder alignment and governance
Scope, timeline, and the split
Frontend migration
Full Site Editing with our Elementary starter theme
Governed design system components
Documenting the entire frontend process
Backend & content migration
Mapping content and structure
Media library and inline references
Workflows and integrations
The failure this prevents
SEO preservation
Pre-migration SEO audit
URL mapping
Redirect implementation at scale
File-format redirects
Canonical tag preservation
Metadata transfer
Internal link audit
Sitemap regeneration
robots.txt validation
Crawl simulation before DNS switch
Post-launch monitoring
Performance gains without ranking loss
Testing, Launch, and Hypercare
Testing
Launch
Hypercare
Enablement
What happens after migration
FAQ
How long does a Drupal to WordPress migration take?
Will we lose SEO rankings during migration?
Can WordPress handle our content complexity?
What happens to our Drupal modules and integrations?
Is WordPress as flexible as Drupal for developers?
How much does an enterprise Drupal to WordPress migration cost?
Can our team maintain WordPress after migration?
Last updated on Jun 5, 2026
How Enterprises Migrate from Drupal to WordPress (Without Breaking SEO, Workflows, or Integrations)
Drupal 7 reached end-of-life in January 2025. The platform stopped receiving all forms of support and updates, including critical security patches, more than a year ago. And yet, as of 10th May 2026, almost 190,000 websites are still on Drupal 7. A cottage industry has come up just to support enterprises not yet ready to migrate. But what’s the endgame? Are these vendors seeking to help you migrate or just making it comfortable to stay on an outdated platform?
Drupal 9 is already unsupported, while Drupal 10’s end of life is scheduled for December 2026. Every major Drupal upgrade requires a rearchitecting effort that costs as much as a full replatform.
If you’re going to spend that budget regardless, the question stops being which Drupal version to upgrade to and becomes more whether WordPress better serves the next five years of your digital operations. This guide covers how enterprises like Al Jazeera and FleetNet America have made that move without breaking anything during the process.
Let’s outline the key reasons causing enterprises to leave Drupal.
Why enterprises leave Drupal
Three triggers cause enterprises to leave the platform.
1. When an upgrade costs as much as a migration
The first one is concerns around every version’s planned end-of-life and the cost of staying current. Every major Drupal version jump demands rearchitecting, and Acquia’s own guidance puts a Drupal 7 to Drupal 10 migration at 16 to 30 weeks of developer time.
When the price of upgrading is comparable to migrating to a different platform entirely, the upgrade is hardly the right choice. For the full cost model, including the 5-year TCO comparison and break-even timeline, see our migration business case.
2. Editorial independence vs developer dependence
The second challenge is the editorial experience. Drupal’s interface assumes the person editing understands technical concepts. Layout Builder, Paragraphs, and custom field configurations are powerful only in trained hands, so content teams will need a developer to make layout changes or build campaign pages.
WordPress, on the other hand, provides full independence to writers through Gutenberg’s block editor and Full Site Editing.
3. Even if you upgrade, is it really worth the effort?
The third trigger is the rebuild exercise itself. Drupal 7 to Drupal 8 was a full architectural rewrite. The later jumps were lighter, but each still required lengthy reworking. You may be absorbing that effort every few years, but is the newly upgraded platform serving your team better?
WordPress does everything Drupal can, plus marketing autonomy
Drupal has earned its reputation for good reasons. The platform handles complex content models and includes granular permissions and multilingual capabilities.
WordPress is more flexible and easier with handling complexity. We built a single WordPress multisite instance for Private Media and helped them run Crikey, The Mandarin, and SmartCompany. Each editorial team publishes independently on a shared foundation, with its own subscriber base and workflows intact. The editors do not need to wait on developers to launch new sections or modify existing ones.
The structural difference is that Drupal optimizes for developers while WordPress optimizes for publishers.
For a side-by-side capability breakdown, see our Drupal vs WordPress enterprise comparison.
rtCamp’s enterprise migration methodology
We have delivered hundreds of Drupal to WordPress migrations across 300+ enterprise migrations over 17 years as a WordPress VIP Gold Agency Partner. The failure patterns across those projects tend to repeat, so we build our methodology around preventing them.
Every migration follows a phased delivery model. The live Drupal site stays up throughout. The WordPress site is built on a staging instance in parallel, and DNS switches only after full testing and client sign-off.
The phased delivery model
The discovery and audit phase defines the scope, identifies the components that migrate and get rebuilt, and ensures all stakeholders agree on the timelines and ownership.
Pilot migration catches data mapping errors before they can spread to thousands of records.
The phased build runs frontend, backend, and content migration workstreams in parallel with mechanisms in place to coordinate all three.
The enablement phase trains the content editors on the new platform before launch. Hypercare provides 30 days of post-launch support to catch anything missed during testing.
Finally, the evolution phase transitions the relationship into ongoing maintenance and growth.
Setting the tone with the discovery phase
We offer 20 hours of free discovery before any contract is signed, and we start within 7 days of engagement. We invest time in the discovery phase to establish the scope of the migration and set the direction for upcoming phases.
The timeline you should expect
The timeline for the migration depends on complexity. For example, we migrated FleetNet America (a part of the Cox Automotive network of sites) from Drupal 9 to WordPress in just a few weeks. Enterprise migrations with custom integrations and multilingual content typically take between 3 and 6 months.
Discovery and planning
We treat discovery as the most important phase of any migration because it sets the tone for the rest of the phases.
Auditing the existing Drupal stack
During this step, we identify every content type in Drupal and document its purpose. We then map the taxonomies and their relationships, understanding how page content is organized and stored in Drupal’s node and entity system and inventorying metadata, forms, and their relevant configuration.
As an agency, we conduct detailed calls to discuss the complete scope of the planned migration, and this includes the extent of the standardization we aim to implement across the brands belonging to an organization.
For the full audit methodology, check out our pre-migration guide.
Stakeholder alignment and governance
The technical audit runs alongside a governance exercise. We define ownership after launch, specifying which team controls the block library, who is responsible for content workflows, and an escalation path to be followed during a conflict between editorial and engineering teams.
See how our OnePress framework handles governed multi-property publishing.
Scope, timeline, and the split
Once the audit and governance model are complete, we define the migration scope in three categories: fully automated, semi-automated with human verification, and manual migration.
We focus on content architecture, editorial workflow design, and team enablement as primary deliverables.
Frontend migration
Migrating Drupal’s presentation layer to WordPress means mapping between two systems that handle page composition differently.
Drupal’s Layout Builder and Panels handle page structure. WordPress handles it through the block editor and Full Site Editing. Drupal regions map to WordPress template parts, and Drupal Views map to WordPress query blocks or custom WP_Query implementations depending on the complexity of the original logic.
See our frontend migration guide for a file-by-file template translation that includes Drupal Twig to WordPress PHP, regions to template parts, and CSS and JS asset migration.
Full Site Editing with our Elementary starter theme
We build block-based FSE themes for our enterprise migrations, and we do not generally recommend classic themes.
Block-based themes give editorial teams direct control over page layout and composition, which is the main advantage of moving off Drupal in the first place. A content team can independently rearrange sections, swap components, and assemble new pages from a library of ready design components. Just add content, and you are ready to publish.
We build every theme on top of Elementary, our open-source FSE starter theme. Elementary keeps the codebase aligned with WordPress core and the block editor roadmap.
Governed design system components
Custom Gutenberg blocks give editors freedom to compose pages while staying within brand guidelines. Each block enforces the typographic, color, and layout constraints defined during the design phase.
The block library, the template hierarchy, and the mapping between Drupal regions and WordPress template parts are documented as we build. The documentation includes the purpose of each block, a list of configurable options, and usage guidance for editors.
Building blocks without governance can invite failure that will show up in the form of editors getting a blank canvas, producing off-brand pages, and causing the organization to lose brand consistency. We prevent that by baking brand constraints into the block architecture for editors to choose from governed components.
Documenting the entire frontend process
We document the entire frontend migration as we go, covering the custom block library, the template hierarchy, the mapping between Drupal regions and WordPress template parts, and any custom queries replacing Drupal Views.
Each block is defined with its purpose, its configurable options, and an example of how editors should use it.
Backend & content migration
Drupal is an open source platform, which means you already own your data. There are no export fees blocking you from migrating your site’s content.
When migrating content, metadata, and taxonomies, the split between automated scripts, semi-automated routines, and manual migration is defined during discovery.
Mapping content and structure
Drupal nodes and revisions become WordPress posts, pages, and custom post types with editorial history preserved. Field API tables convert into wp_postmeta. Vocabularies become categories, tags, and custom taxonomies, all mapped during discovery. Users and roles migrate into wp_users and capabilities, with author attribution retained on every post.
Password hashes cannot survive the move between cryptographic systems, so accounts are imported without passwords, and a global reset is carried out after the migration is complete.
If you would like to learn about the full entity mapping table with Paragraphs to Gutenberg blocks, CCK fields to ACF, and user migration with hash handling explained, consider reading our content migration guide.
Media library and inline references
Legacy assets are referenced from inside post bodies as raw paths, and a bulk importer leaves those references intact across the migration.
Media migration runs in two passes. The first pass involves files with deduplication, thumbnails, alt text, and file naming preserved. The second pass processes every migrated post and rewrites inline references so embedded images and documents resolve to the new library. PDFs and other resources Google has indexed get explicit redirects.
Workflows and integrations
Drupal Content Moderation maps onto WordPress capabilities and custom workflow code.
Approval chains, reviewer assignment, and scheduled publishing carry through against the role mapping established during discovery.
Integrations get rebuilt against their underlying data contracts. Forms, CRM, analytics, and SSO each connect to the WordPress capability set.
Many Drupal modules have direct plugin equivalents, but others need to be purpose-built to match the original installation.
For a detailed Drupal module to WordPress plugin equivalents table and the hook system translation guide, see our backend migration guide.
The failure this prevents
A migration looks fine at launch, and six months later the editors discover that 12,000 posts have meta fields stored as raw text or internal links pointing to dead Drupal node IDs.
The cause is almost always a bulk import that skipped field-by-field mapping. We make sure our scripts are idempotent. Running them produces the same end state every time, and each pass is verified against a measurable count before the next pass runs.
SEO preservation
SEO loss is a rational fear for any marketing or IT team during a Drupal to WordPress migration project. A botched migration can erase years of search rankings, and the recovery curve can be long. The SEO preservation step therefore deserves careful attention.
Pre-migration SEO audit
Every URL on the live Drupal site is recorded using Screaming Frog, a tool that runs against the production domain and exports a complete list of URLs, response codes, canonical tags, meta titles, meta descriptions, Open Graph tags, schema markup, image alt text, internal links, and external links.
Alongside the crawl, we pull backlink data from Ahrefs or Semrush to identify the URLs that carry external link equity. The high-value URLs are flagged separately. Losing rankings on a long-tail page is recoverable, but losing rankings on a URL with hundreds of referring domains will be a lot more troubling.
Before we start, we capture a baseline of your keyword rankings. The baseline includes the top-ranking queries, the URLs that rank for them, and the position they occupy. After launch, this baseline becomes the comparison set, and any deviation outside the expected variance is investigated.
Core Web Vitals are captured in the same way. Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift are pulled from CrUX and PageSpeed Insights, segmented by content type.
The baseline should give the migration team a measurable target for the new site.
URL mapping
The crawl output is the basis of the URL mapping table, with every Drupal URL is mapped to its WordPress destination, one row per URL.
Drupal’s Pathauto module generates URL patterns from content type and taxonomy tokens. WordPress uses a different permalink structure built around the permalink template and the post slug.
Vanity URLs from Drupal’s URL Aliases table are preserved separately. These are URLs that an editor manually set on a node, and they often carry significant SEO weight because they were chosen for keywords.
Redirect implementation at scale
Once the URL mapping is complete, the redirect implementation begins. We implement URL redirects directly in the web server using a lookup table.
For sites on WordPress VIP, WPCOM Legacy Redirector handles large volumes of legacy 404 redirects, while Safe Redirect Manager covers smaller sets and pattern-based rules. Both store redirects in the WordPress database, with VIP’s edge cache in front so repeat requests are served without running any PHP code.
Redirect chains should not be permitted, so A goes to C, never A to B to C. Redirect loops are caught through a validation script that walks the entire redirect graph. Every redirect returns HTTP 301, which signals permanent relocation and consolidates the link equity from the legacy URL to the new one.
File-format redirects
In one of our Drupal to WordPress migration projects, the legacy CMS and WordPress handle uploaded files differently, including the path structure and the file naming logic. PDFs that Google had crawled and indexed were at one URL on the source site and at a different URL on WordPress, with the file content identical. Without explicit redirects, those PDFs returned 404.
Since then, we’ve added file-format redirects as a separate validation step in our SEO migration blueprint. The crawl output is filtered for non-HTML resources, including PDFs, DOCX files, images that rank in image search, and any other indexed assets, and each one gets a 301 to its new location in WordPress.
Canonical tag preservation
Canonical tags are validated separately from metadata transfer. The pre-migration audit captures the canonical URL for every page on the live site, including pages where the canonical was deliberately set to a URL other than the page’s own.
After migration, the canonical tag on every WordPress URL is verified against the audit.
Metadata transfer
Some metadata fields are transferred field by field. Others are regenerated on WordPress because the plugin produces the same result more cleanly. The approach is decided during discovery based on an audit of how the legacy site’s SEO module was being used.
Yoast SEO and Rank Math generate canonical tags, OG tags, Twitter cards, and basic structured data automatically from WordPress content.
Internal link audit
Enterprise Drupal sites accumulate thousands of internal links, and a generic import only preserves the link text. The link text on the new WordPress page still points to a Drupal path that the server-level redirect resolves correctly, and that redirect adds a hop to every internal navigation and crawl request.
Our migration scripts rewrite every internal link inline as part of content transfer. The post body in WordPress contains a direct link to the new WordPress URL, with no redirect dependency. The pre-migration audit lists every internal link in every post, and the post-migration audit verifies that every one of them points to a valid WordPress URL.
Sitemap regeneration
Drupal’s XML sitemap is replaced with a WordPress sitemap generated by Yoast or Rank Math. The new sitemap is validated against the URL mapping table to confirm every expected URL is present and no legacy paths are leaked. After launch, the sitemap is submitted through Google Search Console and Bing Webmaster Tools, and the indexation report is monitored daily for the first month.
robots.txt validation
Every disallow rule in the Drupal robots.txt is reviewed against the current site, and only the rules with a valid reason are replicated on the destination WordPress site. The WordPress robots.txt is written from a clean state and validated through Search Console’s robots.txt tester.
Crawl simulation before DNS switch
The final validation before launch is a full crawl of the staging WordPress site, with the staging domain rewritten in the crawler to simulate the production URLs. All elements are compared against the pre-migration baseline.
See our SEO migration checklist to learn how we preserve SEO equity across migrations.
Post-launch monitoring
After the DNS switch, the same crawl runs against the production WordPress site to confirm the staging validation’s results. Google Search Console is monitored for indexation rate, 404 reports, crawl errors, and Core Web Vitals field data.
We closely monitor the first 30 days for any search ranking volatility.
Performance gains without ranking loss
A correctly executed migration produces stable search rankings and measurable performance improvement on the same launch.
For instance, FleetNet America, part of the Cox Automotive network of sites, moved from Drupal 9 on Acquia to WordPress VIP and saw a 2x improvement in Core Web Vitals through the migration. The SEO baseline remained intact, and the performance baseline rose on the same project.
If you’d like to see more migration results with consistent metrics delivered, please check out our case studies.
Testing, Launch, and Hypercare
Before the migration goes live, three conditions need to be in place:
- The new site has to match the old one in functionality, with no regressions in content, URLs, or editorial workflows.
- The cutover has to happen without downtime, and readers and search engines should be unaffected by the switch.
- The team taking over has to know how to run the platform daily on their own.
Testing
Cross-browser and cross-device QA covers the latest versions of Chrome, Safari, Firefox, and Edge on macOS, Windows, iOS, and Android.
Alignment and responsiveness issues are recorded and fixed as they surface.
Third-party integrations are tested in a sandbox environment that mirrors production, including form handlers, CRM endpoints, analytics, and the tracking layer carried over from the old site.
Editors can then run their daily workflows on staging using their own migrated content, including drafting, scheduling, approvals, media uploads, and translations where relevant.
Our QA team stays on alert at this stage to record any issues caught by editors.
For the complete testing protocol with visual regression tooling, content parity validation, and the go/no-go checklist, visit our testing and QA guide.
Launch
Launches happen on weekdays during business hours, with both teams present. A blue-green deployment runs alongside the live site, the DNS switch is the cutover, and instant rollback is provisioned. We have not had to activate it.
The first 24 hours after migration are monitored live for traffic, error rates, Core Web Vitals, and anomalies in Google Search Console data.
For Psychopharmacology Institute, we executed the platform switchover from Django and React to WordPress in under six hours with zero downtime. 3,000+ subscribers carried over to the new platform, and the operations team regained full platform control on day one.
Hypercare
Hypercare begins immediately after go-live. Daily standups run through the first week and taper as the site stabilizes. A single rtCamp point of contact is assigned to you, with a bug-triage SLA in place for the warranty period. SEO is monitored during this window, including index coverage, redirect health, and ranking movement for priority keywords.
Rankings have stayed intact or risen across our migrations, with no missed redirects surfacing post-launch, because the URL mapping and metadata work is done before the DNS switch. Scheduled performance tests catch regressions before users do.
To know more about the full post-migration protocol that covers 30-day GSC triage, performance optimization, security hardening, and the training handover framework, read our post-migration guide.
Enablement
Enablement is delivered as PDF documentation and live training sessions for each role on the client’s side. Editors get hands-on sessions covering the visual editor, the Gutenberg block library built for their site, scheduling and revisions, and the moderation workflow.
Marketing and site administrators get a separate session covering user roles, capabilities, plugin usage, and the customizer. Every session is recorded, and the documentation is written specifically for the client’s implementation.
The training schedule is set based on the trainees’ skills. The training schedule will span around 6 calendar weeks, which include workshops for trainees.
What happens after migration
After delivery, clients move into one of three collaboration models depending on their needs. The choice is decided once the team gets a real sense of how much ongoing engineering effort they want to own.
Managed site maintenance is for the team that wants to focus on editorial output and let us handle the platform. We take ownership of plugin updates, security patches, performance monitoring, uptime, and the routine engineering work that keeps a WordPress VIP or self-hosted site healthy.
WordPress Growth is for the team with a live roadmap. It runs on a block-hours arrangement, so engineering capacity is available for new features, integrations, A/B experiments, performance tuning, and the iterative work that builds up after launch.
Staff augmentation is for the team that needs senior WordPress engineers embedded inside their own delivery structure. We assign engineers who report to the client’s tech lead, attend their standups, and work inside their tools and processes. This is common with enterprise clients that have strong internal product teams and want WordPress depth without hiring for it directly.
FAQ
How long does a Drupal to WordPress migration take?
Complex enterprise sites with custom integrations typically run from a few weeks to a few months.
Cox Automotive’s FleetNet America site was migrated from Drupal 9 on Acquia to WordPress VIP in a few weeks.
Acquia’s own guidance puts a Drupal 7 to Drupal 10 upgrade at 16 to 30 weeks, and the WordPress migration is usually comparable or shorter.
Will we lose SEO rankings during migration?
Not if SEO preservation is treated as a pre-migration deliverable. We map every URL, validate redirect chains, record Core Web Vitals before and after the migration, and migrate metadata field by field.
Cox Automotive’s FleetNet America site saw a 2x improvement in Core Web Vitals after the move to WordPress VIP, with search rankings intact.
Can WordPress handle our content complexity?
Yes. Custom Post Types, custom taxonomies, Advanced Custom Fields, and the Block Bindings API in WordPress 6.5+ can replicate any Drupal content model.
rtCamp has completed 300+ CMS migrations and has not run into a Drupal-specific feature that could not be rebuilt in WordPress.
What happens to our Drupal modules and integrations?
Modules do not always map one-to-one. They map to a combination of WordPress core features, custom plugins, and purpose-built integrations. The discovery phase audits every module and to decide between migrating or retiring them. The goal is to rebuild the capabilities that are necessary for your organization or business.
Is WordPress as flexible as Drupal for developers?
Yes, with one honest caveat. Drupal does have things WordPress does not give you in core, including a native Entity API, configuration as YAML, and granular role-based access control.
However, developer flexibility in Drupal may turn out to be challenging for editors, who need to frequently contact developers for changes.
WordPress, along with established plugins, gives both developers and editors the flexibility and user-friendliness to speed up your organization’s daily operations.
See our comparison guide for a full Drupal vs WordPress comparison.
How much does an enterprise Drupal to WordPress migration cost?
Enterprise migrations with complex integrations, multilingual content, and workflow translation start at $50,000 and can cross $200,000 depending on the scope of the migration.
We run 20 hours of free discovery to map your architecture and give you a real number before any contract is signed.
Can our team maintain WordPress after migration?
Yes, that is the entire goal of the migration. Documentation for engineers and editors is among the deliverables we provide, and we run live training sessions on staging using your migrated content.
The 30-day hypercare period after launch covers anything testing missed, with a single point of contact and a bug triage SLA. After their WordPress VIP migration, the Cox Automotive FleetNet America team said the platform “empowered our team to manage the CMS efficiently, freeing up our core engineers for larger initiatives.”
Drupal EOL is a deadline. It doesn’t have to be a crisis.
We’ll map your current Drupal architecture, identify what migrates and what gets rebuilt, and help you build the internal case.
Business case for migration
NEXT
Credits
Naweed Chougle
Author
Naweed Chougle
Author
Naweed is a Senior Technical Content Writer at rtCamp, specializing in WordPress and enterprise CMS content. With over ten years of experience in the WordPress ecosystem, he creates blog posts,…
Aviral Mittal
Editor
Aviral Mittal
Editor
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
cookies.js_dtest
This cookie determines whether the browser accepts cookies.
session
_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
Toggle SalespanelSalespanel
Salespanel is a B2B marketing and sales software that identifies, tracks, and qualifies website visitors and leads in real-time using first-party data. It helps businesses monitor customer journeys, score leads based on behavior, and syncs this data with CRMs (like Pipedrive or HubSpot) to improve conversion rates.
Service URL: salespanel.io (opens in a new window)
Name
Description
Duration
track_uid
Identify and tracking a lead
12 moths
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