Project Overview and Our Working Approach We are commissioning two high-performance WordPress platforms to replace legacy ASP.NET systems. This is a strict greenfield deployment on a managed Linux Virtual Private Server (VPS). We are abandoning all historical database records to ensure absolute architectural purity. The critical defining factor of this project is enterprise-scale data volume. We are opening our platforms to external job board aggregators. The successful engineer must build an infrastructure capable of processing, indexing, and serving up to 300,000 active job nodes daily without compromising front-end speed. The Deliverables Both platforms require 100% functional feature parity with our existing live systems, achieved natively without bespoke PHP frameworks. Platform 1: www.jobsearchplace.co.uk (High-Volume Aggregator) Architecture relies on the Astra Pro theme paired with WP Job Manager, acting strictly as a lightweight visual shell. This platform must ingest and manage up to 200,000 active XML job nodes daily from external aggregators. You must map the external application URLs so candidates bypass internal forms and redirect directly to the source. Platform 2: www.qualifiedfinder.com (Hybrid Marketplace) Architecture relies on the WorkScout theme paired with WooCommerce and WP Job Manager. You must implement WorkScout's native peer-to-peer freelance task-bidding mechanics, private messaging, and milestone payments. Concurrently, the platform must ingest up to 100,000 active XML job nodes. You must establish strict database taxonomy ensuring user-generated freelance gigs never intersect with the automated XML job listings during front-end searches. Core Technical Mandates (Non-Negotiable) Enterprise Search Indexing: Native WordPress MySQL queries will instantly time out when filtering 300,000 custom post types. You must implement a dedicated search index (such as ElasticPress/Elasticsearch or Algolia) to ensure instantaneous front-end candidate filtering via Ajax. WP-CLI and Server Cron Automation: Web-based XML imports are impossible at this scale. You must configure WP All Import Pro to execute via WP-CLI using strict server-level Linux cron jobs. Imports must be batched efficiently to prevent database lockups. SEO Preservation (301 Redirects): Because we are abandoning the legacy database, the old ASP.NET URLs will cease to exist. Before the DNS switch, you must crawl the live platforms, extract all indexed URLs, and map permanent 301 redirects to the new WordPress permalink structures to protect our historical search rankings. What We Expect in a Working Relationship We require an independent technical partner. If a requested feature threatens database stability at the 300,000-post scale, you must push back and present a leaner alternative. Adherence to standard CMS architecture and strict documentation of your WP-CLI scripts and indexing logic are mandatory. To Apply Please begin your proposal by answering these three technical questions: When importing 200,000 fresh jobs via WP All Import, how exactly do you configure the WP-CLI scripts and server-side cron jobs to prevent memory exhaustion and database locking? How will you configure Elasticsearch or an equivalent indexing solution so the front-end Ajax filters can search 300,000 wp_postmeta records across two sites with sub-second latency? Technically, how will you execute the 301 redirect map for thousands of legacy ASP.NET URLs to ensure Google does not penalise the domains for 404 errors post-launch?