/handbook/drupal-to-wordpress-migration-guide/post-migration/
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 Site launch
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
Launch preparation (Go-live readiness)
Go-live
Push the new site live
Enable WordPress SEO indexing
Run smoke tests on the live site
Check redirects
Monitor for errors
Minimize downtime
Troubleshoot launch issues
Final go-live announcement
Post-launch validation and monitoring
Team training and handoff
Ongoing maintenance and optimization
Post-launch bug fixes
Performance tuning
SEO monitoring & enhancement
Content strategy adjustments
Security maintenance
Analytics and conversion tracking
Iterative improvements
Cost and infrastructure review
Reflect
Last updated on May 28, 2026
Drupal to WordPress Post-Migration and Launch
Now that the testing phase is done, it’s time for the launch. This is when everything you’ve worked on during the migration comes together and your new WordPress site goes live. However, the launch is just the beginning of the post-migration journey.
It’s crucial to ensure that the transition from Drupal to WordPress is seamless, that all functionalities are working as expected, and that your team is prepared for ongoing maintenance and optimization. We’ll now walk through the key steps and best practices for launching your site and handling post-migration tasks to ensure long-term success and stability.
Launch preparation (Go-live readiness)
The launch phase involves switching from the old CMS to the new WordPress site with minimal disruption. Preparation is key to ensure a seamless go-live. Here’s how to go about it.
- Final content freeze: Communicate and enforce the content freeze on the old site as the launch window nears (if not already in effect). No new content or changes should be made on the old CMS that haven’t been migrated. If absolutely needed (e.g. a critical announcement), have a plan to update it manually on both old and new until cutover.
- Update final content changes: If there have been any content updates on the staging site during QA (or content prepared to go live at launch, such as new blog posts or announcements timed with launch), make sure those are finalized. Double-check that any time-sensitive content is scheduled or ready on WordPress.
- Rehearsal/Dry run: If possible, do a dry run of the launch in a low-stakes environment. For example, if you can temporarily switch a hosts file to point your domain to the new server or use a test subdomain, do so to simulate the go-live and see if everything still works on the live domain. This can catch issues with domain-specific configurations (like cookie domain settings, API callbacks, etc.).
- DNS and hosting prep: Ensure you have access to DNS settings for your domain, and know exactly what record changes are needed (if moving to a new host or IP). Lower the DNS TTL a day or two before launch to allow quicker propagation (if applicable). If using the same domain on a new server, confirm the new hosting is ready to serve that domain (virtual hosts configured). If the domain is changing, prepare any necessary domain redirects.
- Backup old site: Take one more full backup of the old site right before launch (even if you did earlier) so you have an up-to-date copy of content and data at the moment of transition. This is your fallback if something goes wrong or if you later need to retrieve something not migrated.
- Enable maintenance mode (Optional): Some teams choose to put the old site into a read-only or maintenance mode during the actual switch, especially if the switch might cause a brief downtime. For example, you might display a notice like “We are upgrading our site, back in a few minutes” if the cutover cannot be instantaneous. Prepare this if needed (WordPress has maintenance mode plugins, or you can use an interim holding page via DNS).
- Coordinate team for launch: Schedule the launch for a time that has minimal user impact (off-peak hours or a weekend, if suitable for your business). Ensure all relevant team members are on call or online during the launch window – this includes developers (to execute the technical steps), an IT/ops person (for DNS or server changes), someone from QA or content to quickly check the live site, and possibly a representative from marketing or leadership to approve once live. Have a communication channel (like a Slack room or conference call) open for real-time coordination. Everyone should have the runbook of steps and know their role.
- Security & monitoring setup: Before launch, set up any monitoring tools on the new site. For example, have uptime monitoring ready to alert if the site goes down, set up monitoring in Google Search Console (which might later alert to any crawl issues), and ensure error logging on the new server is enabled so you can catch issues. Also, if using any web application firewall (WAF) or CDN, get ready to enable it or switch it to point to the new site.
- Plan for rollback: Have a rollback plan outlined. For instance, if after switching something is wrong, be ready to restore the old site (perhaps at a backup URL or by reverting DNS to the old server which is kept running until you confirm success). Know how to quickly revert DNS or have a maintenance page to put up if needed. Having backups and possibly an export of the latest content changes from WordPress (in case you need to re-import to a fresh instance) is part of this.
By thoroughly preparing, you reduce the chance of any oversight during the hectic moments of launch. The aim is to minimize downtime and ensure a seamless transition.
Go-live
With preparation done, execute the launch step by step:
Push the new site live
This typically involves making the new WordPress site respond to the production domain. If the new site is on a different server, update DNS to point the domain to that server’s IP. If using a service or platform, you might just remove password protection or announce it. Sometimes, teams swap the domain by updating domain settings in WordPress and then flipping DNS. Follow your plan closely.
Enable WordPress SEO indexing
As soon as the site is live (or just before flipping the switch), ensure you allow search engines to index the site. This means disabling any maintenance mode or login restrictions and unchecking “Discourage search engines from indexing this site” in WordPress Settings > Reading (which you likely had on during development). If you had a robots.txt disallow or password protection, remove those. This allows Google and others to crawl the new site.
Run smoke tests on the live site
The moment the new site is live on the production domain, do a quick round of critical tests:
- Load the homepage and a few other pages to ensure they display correctly.
- Test a form submission on the live site.
- Click important navigation links.
- Verify that the SSL certificate is working (if the site is HTTPS, the certificate must be in place on the new server – check for any mixed content warnings too).
If anything is broken in these immediate smoke tests, address it quickly if possible (for example, if you find a redirect missing, you can add it on the fly). This is to catch any obvious issues that might have arisen due to the domain switch or environment differences.
Check redirects
Test a sample of old URLs (perhaps from a list of top pages or various sections) by typing them into the browser or via a tool. They should redirect to the new site pages (and end up showing the new content). If any fail (result in 404), you may need to adjust your redirect rules.
Monitor for errors
Keep an eye on monitoring tools. If your new host has an error log, watch it for any significant errors in the first hour or so. Also monitor the site’s general health (CPU, memory on server if applicable) to ensure the new site is handling traffic.
Minimize downtime
Ideally, if done correctly, downtime is just a few seconds or minutes while DNS propagates. But to be safe, ensure that the old site or a maintenance page covers any gap. The goal is users never hit a dead end. If something is taking longer than expected, communicate via the maintenance page or via social channels to users if appropriate (“We’re migrating, be right back”).
Troubleshoot launch issues
If any critical issue arises (for example, site not loading for some users due to DNS, or a plugin behaving differently on production), have your team troubleshoot immediately. It might be as simple as clearing caches or as complex as a quick code fix – that’s why having developers on hand is crucial.
Use your escalation points if needed (for instance, if an integration isn’t working, contact that service’s support quickly). In the worst case, decide if rollback is needed (if the issue will take too long to fix and the site is essentially down). Usually, careful testing prevents this scenario.
Final go-live announcement
Once you are confident the site is up and running correctly, inform stakeholders that the new WordPress site is live. Often an organization will send out a communication internally (and sometimes externally) that the new site is launched.
From a marketing perspective, you might announce the new website via a blog or press if it’s a notable improvement. Make sure the front-line staff (like customer support or sales) are aware, in case they get any queries or notice anything odd, they know a migration happened.
The site is now officially running on WordPress. Congrats on the launch! But the work isn’t done — the post-migration period is critical to validate the success of the migration and address any lingering issues.
Post-launch validation and monitoring
After launching, conduct a comprehensive post-migration validation to ensure everything is truly working on the live site, and to catch any issues that slipped through or arose due to the live environment:
- Full Site Crawl & 404 Monitoring: Use tools like Google Search Console, Bing Webmaster Tools, or a site crawler to identify any broken links or missing pages. Google Search Console in particular will start reporting crawl errors (404s) after the new site is indexed. Proactively, you can run a crawler on the live site to see if all internal links resolve and if any references to old URLs remain. Set up a 404 monitoring plugin or check your server logs for 404 errors. For any 404s that appear (especially ones that were not anticipated), create appropriate 301 redirects to handle them. This might happen for less common URLs or typos that were out there. Addressing these quickly preserves SEO and user experience.
- SEO Performance Checks: In the days and weeks immediately following, keep a close eye on SEO metrics. Check that search engines have fetched the new XML sitemap and are indexing the new pages (look for your pages in Google using site: search). Monitor keyword rankings for any drastic changes. Some fluctuation is normal after a migration, but if something plummets, investigate if a SEO element was missed (for example, maybe a noindex was accidentally left on, or a section of URLs wasn’t redirected correctly). Also compare organic traffic: there might be a dip initially, but it should recover if all was done well. Continue using Google Search Console to track indexing status and any HTML improvements or warnings it provides.
- Analytics Verification: Confirm that Google Analytics (or other analytics) is collecting data properly on the new site. Compare traffic levels pre and post (though make sure you account for the launch timing). Also check conversion tracking if you have goals or e-commerce tracking – ensure forms or sales are being recorded in analytics as before. If you find a discrepancy, you might need to adjust settings (perhaps update a goal URL if it changed, etc.).
- Functionality re-check: It’s wise to do another run-through of key site functions on production a day or two after launch. Sometimes email from the live server might behave differently, or an API might have a live endpoint that needs reconfirmation. Have team members or select users continue to use the site and report any odd behavior. For example, maybe a user finds they can’t log in (could indicate an issue with an account migration), or an editor finds they don’t have permissions to something (perhaps a role adjustment needed). Resolve these as they come in.
- Performance and load monitoring: With real users hitting the site, monitor the performance. Ensure the caching is effective and adjust if needed (e.g., if certain pages aren’t caching and causing high load). If you see slow load times or spikes in server usage, investigate and optimize. Also check that your CDN (if used) is caching assets and that there are no hot-linked resources still pointing to the old server (which might now be offline).
- Security review: Post-launch, do a security sweep. Make sure only the necessary user accounts exist on the WordPress site (remove any test or placeholder accounts used during development). Enforce strong passwords for all users. Ensure the site is properly configured (file permissions, no debug mode on, etc.). If not already done, implement additional security measures like enabling a WAF, or at least making sure backups are running for the new site. The CTO or security team might run a vulnerability scan – be prepared to fix any issues found (e.g., update a plugin if a new version is out, etc.).
- Old site decommissioning: If the old CMS was on a server, coordinate to decommission it safely. Usually, it’s wise to keep the old site in an archive form for a while (or at least don’t immediately destroy the data). Perhaps restrict public access to it (to avoid duplicate content issues – it should ideally be offline or behind password). Once you’re confident the new site has everything and no rollback is needed, you can uninstall or shut down the old system, which may save costs and reduce security exposure. But keep the backups!
- Gather feedback: Encourage the internal team and even users to report any issues they find. You might set up a temporary feedback form or an email alias for the new site launch feedback. Often, real users might find small things – maybe a missing PDF, or a typo, or something that wasn’t considered. Address these quickly to improve the site.
- Compare metrics to baseline: Remember the success metrics defined at the start? Now is the time to start collecting data for them. Compare site speed (is it faster on WordPress?), check if the editorial team finds it easier to publish (qualitative feedback), monitor SEO (did rankings hold steady or improve for the targeted areas?), check if bounce rate or pages per session improve due to better UX, etc. It might be too early to see big changes, but start analyzing and share early results with stakeholders to show progress or identify if any goal is not being met so you can adjust.
- Post-launch SEO actions: Submit the new sitemap to Google Search Console and Bing if not done immediately at launch. Also consider a blog post or press release about the new site (if appropriate) which can generate some buzz and maybe links. If your domain changed, ensure you update your backlinks by contacting important partners or directories. Essentially, cement the new site’s presence everywhere the old site was referenced.
During this immediate post-launch period (often 1-2 weeks referred to as a “hypercare” or stabilization period), it’s normal for the development team to fix a few bugs and for the content team to make minor adjustments. Stay agile and address issues rapidly. Logging these fixes is useful for transparency. The objective is to reach a state where the site is stable, all critical issues are resolved, and performance/SEO is trending in the right direction. Typically when you work with a development partner like rtCamp, this period is covered as part of the migration project.
Team training and handoff
Now that the site is live on WordPress, ensure a smooth handoff to the teams who will own its day-to-day operation:
-
Editor and contributor training: Conduct training sessions for content authors, editors, and marketers on using the WordPress admin interface. Show them how to create and edit content, manage media, use any new plugins (for example, SEO meta box usage, form entry viewing, etc.), and outline any changes in workflow from the old CMS. Highlight new capabilities they have (maybe things that were hard in the old system but easier now, like embedding a video or creating a new landing page). Provide cheat sheets or quick reference guides for common tasks. This training will help the marketing/SEO team feel comfortable and take full advantage of WordPress.
-
Admin/developer knowledge transfer: If a development or IT team will maintain the site, ensure they know how the site is set up. Walk through the codebase (theme/plugins), point out any custom scripts or configurations, and pass on credentials or access information securely. If you engaged an outside team for the migration, they should document custom code and decisions for the internal team. Also, show how to deploy changes (if using version control or certain hosting workflows). Essentially, transfer the technical knowledge needed to maintain and troubleshoot the site.
-
Documentation: Compile documentation for the site. This can include:
- A content editorial guide (how to add posts, what the content model is, how to use categories/tags appropriately, any templates for content).
- A technical manual for the site (list of installed plugins and their purpose/configuration, how backups are done, how to run the site locally if needed, etc.).
- SEO/analytics guide (where to update meta tags, how to monitor SEO using plugins or Search Console, how to view analytics).
Share this documentation with relevant teams. It’s also helpful to keep a copy in a shared knowledge base or intranet for future onboarding of new team members.
-
Roles and permissions check: Now that real users are using the system, verify one more time that each user has the correct role and that those roles have appropriate capabilities. For example, ensure authors can only edit their own posts if that’s desired, editors can publish, etc., and that no one has admin access except those who truly need it. Principle of least privilege will improve security. Adjust if necessary and remind users about security (like not sharing accounts, etc.).
-
Support plan: Identify who will support the site and how issues will be handled going forward. For instance, determine which developer or team is responsible for bug fixes or enhancements, and how the marketing team will request those (ticket system, emails, etc.). Set expectations that now that the site is live, content changes are in their hands, but technical changes might need to be scheduled. If you have an SLA with a hosting provider or external support, ensure those contacts are known to the team. In the immediate weeks post-launch, you might have daily check-ins to discuss any issues, gradually scaling back as things stabilize.
A well-trained team and clear documentation ensure the organization can run the new WordPress site effectively. This addresses the non-technical handoff side of the project, making sure the marketing/content teams (CMO’s organization) are empowered and the technical team (CTO’s organization) has control and understanding of the system. At rtCamp, such training and documentation is also part of the migration handover process. Read more about our migration to WordPress services.
Ongoing maintenance and optimization
A website migration doesn’t end at launch; it transitions into ongoing maintenance and continuous improvement:
Post-launch bug fixes
Be prepared to fix bugs that are discovered post-launch. Despite thorough testing, real users or edge cases might reveal issues (e.g., an odd page that wasn’t checked, or a browser-specific glitch). Have a process to log these issues (maybe a dedicated “post-migration” bug tracker) and address them promptly. Quick fixes in the days after launch can greatly improve stakeholder confidence.
Performance tuning
After observing the site under real traffic, perform any needed performance tuning. This could involve enabling further caching, optimizing database queries (if any slow queries are noted), adding a CDN if not already, or tweaking server resources. Ensure the site remains fast and stable even under peak load. This is both a technical concern (for developers/IT) and a business concern (fast site improves SEO and user experience, which marketing and sales care about).
SEO monitoring & enhancement
Continue to monitor SEO over the next several months. If rankings or traffic dropped for certain pages, investigate why. Sometimes additional optimization or outreach (to update backlinks to point to new URLs) is needed. Also, capitalize on new SEO opportunities now that you’re on WordPress – perhaps adding an SEO plugin will allow you to improve meta tags or site structure. The SEO team should run analyses and provide recommendations for further improvements (like adding schema markup, improving content on pages that underperformed, etc.). You want to not only preserve SEO but ideally improve it post-migration.
Content strategy adjustments
With WordPress, the content team might find new efficiencies or decide to clean up content. Encourage an ongoing content review process – for example, unpublishing content that no longer fits or updating old content for freshness. The migration may have highlighted some content gaps or excess that can now be addressed routinely.
Security maintenance
Keep WordPress core, plugins, and themes up-to-date. Regularly apply updates (which is now an ongoing task for the engineering/IT team or whoever maintains the site). Outdated plugins can pose security risks, so have a schedule or service for updates (WordPress can auto-update minor releases and plugins if configured). Also maintain regular backups of the new site (most hosts or plugins can schedule daily backups – ensure this is active and tested). Consider periodic security scans or using a security service to catch vulnerabilities. Basically, integrate the site into your organization’s IT security regimen.
Analytics and conversion tracking
Post-migration is a good time to review your analytics and conversion tracking setup. The site structure might have changed, so ensure your funnels (e.g., a user flow to contact or purchase) are still tracked properly. Use the data coming in to see if the new site is meeting user needs. For example, if certain pages have high bounce now, maybe something’s off that needs fixing. Or if time on page increased, that could indicate improved engagement. Share these insights with the marketing team to celebrate wins or target areas for improvement.
Iterative improvements
Plan for a phase of enhancements after the migration. There may have been features or nice-to-haves that were out of scope to get to launch on time. Now you can gradually implement those if still desired (for example, maybe integrating a new marketing tool, or enhancing the design on some section). Also, any feedback from users or stakeholders that was deferred can now be revisited and potentially addressed. Keep a backlog of such improvements and prioritize them with the relevant teams.
Cost and infrastructure review
Involve procurement or finance to review the new ongoing costs. Likely, moving to WordPress (especially if self-hosted) might save on licensing costs from an expensive DXP. Document these savings. Conversely, ensure any new costs (plugin subscriptions, hosting fees) are accounted for in budgets. Make sure any old contracts (with the previous CMS vendor or hosting) are properly closed out to avoid redundant expenses.
Reflect
Gather the team to discuss what went well and what could have been better. Document these findings for future reference. Migrations are learning experiences, and if you’ll ever undertake another (or even just major site projects), these insights are invaluable.
By committing to ongoing maintenance and optimization, you ensure the site remains healthy and continues to meet the organization’s needs. A migration is the beginning of a new phase for the website, and with WordPress’s flexibility, you have a solid foundation to grow and adapt the site over time.
Here’s a post-migration (validation & maintenance) checklist to use during and after launch to confirm a successful migration and proper follow-through:
- Live site functionality verified: Immediately after launch, key pages load correctly on the public site. No obvious broken elements or errors on the homepage and major sections.
- Redirects working: Old URLs tested are redirecting to new URLs (no unexpected 404s). A 404/logs check post-launch has been done and any missing redirects are added.
- SEO preservation confirmed: New XML sitemap has been submitted to search engines. Google Search Console is not reporting critical errors (noindex issues, server errors). Rankings and organic traffic are being monitored with no alarming drops (small fluctuations aside).
- Analytics tracking: Analytics data is coming in for the new site. Key conversion paths or goals are firing correctly. No gaps in data collection due to the migration.
- Performance monitored: The site remains stable under real user load. No significant performance issues have appeared. Uptime is as expected.
- Post-launch issues resolved: Any bugs or content issues identified after go-live have been logged and fixed promptly (broken links, missing content, formatting issues, etc.).
- Team access & training completed: All users have appropriate access to the new site (developers with admin, editors with editor roles, etc.). The content/marketing team has received training and documentation on using WordPress. They are comfortable performing their regular duties in the new CMS.
- Stakeholder approval: Stakeholders (CTO, CMO, etc.) have reviewed the live site and confirmed it meets requirements. Marketing confirms SEO and content are intact, Sales confirms lead forms working, Legal confirms compliance, etc.
- Old system retirement: The old site has been cleanly retired or secured. No traffic is going to the old site (and if it is, it’s being redirected). Old servers or services are scheduled for shutdown per plan, and related expenses are addressed. All legacy data is archived/backed up safely.
- Security measures in place: WordPress security best practices are implemented on the new site (regular backups, updates, monitoring, least-privilege accounts). Any post-launch security audits or scans have been passed.
- Documentation handed over: Migration documentation, new site guides, and any credentials have been handed off to the responsible teams. There is clarity on who maintains the site going forward and how to contact support if needed.
- Success metrics tracked: A process is in place to measure the migration’s success against the initial goals. Baseline vs current metrics will be reviewed after an appropriate period (e.g., 1 month and 3 months post-migration) to evaluate outcomes like SEO performance, user engagement, and cost savings.
Completing this final checklist ensures that the migration project is truly wrapped up. At this point, you’ve fully transitioned from your Drupal stack to WordPress, and everything should be functioning as intended. However, the work doesn’t stop here. Post-migration monitoring, performance optimization, and ongoing maintenance are essential to keep your site running at its best.
Credits
Disha Sharma
Author
Disha Sharma
Author
Disha Sharma is a Content Writer at rtCamp with over a decade of experience at the intersection of technology, digital marketing, and enterprise content strategy. Her WordPress roots run deep, her …
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