Most website RFPs tell the same story. They describe how the new site should look, list the features the organisation wants, set a launch deadline and ask suppliers to price the work. Then the proposals arrive and feel difficult to compare, the shortlisted agencies struggle to differentiate themselves and the platform eventually creates as many operational problems as it solves.
The problem is not necessarily the procurement process. It is what the brief has been designed to measure.
Conventional website RFPs are often written to procure a launch. A stronger WordPress RFP asks a bigger question: what platform, operating model and technical relationship is the organisation procuring for the next five years?
That means looking beyond design and development to include integrations, editorial workflows, migration, accessibility, technical risk, hosting, support and continuous improvement.
Why Many WordPress RFPs Describe the Wrong Thing
When stakeholders are asked what they want from a new website, they naturally answer in terms of what they can see. A redesigned homepage. Better navigation. A clearer resources section. New campaign landing pages. A form that works properly on mobile.
These are legitimate requirements, but they are surface requirements.
What is often left undescribed, and is much harder to recover from later, is the operating model. Who will own and run the platform once it is live? How will content be created and approved? Which systems must remain connected? What happens when an integration fails? What does the support relationship look like six months after launch?
RFPs assembled from departmental wish lists tend to reflect what each team wants to add to the website rather than what the organisation needs the platform to achieve. An RFP built around features will attract feature-led proposals. An RFP built around outcomes, constraints and operational reality is more likely to attract suppliers who understand what the platform is actually for.
Start With Organisational Outcomes
Before listing detailed requirements, a well-constructed WordPress RFP should answer four questions clearly.
What must improve? Move beyond “we need a new website”. Explain whether the organisation needs to generate better enquiries, make content easier to find, support more regions, reduce manual administration, improve accessibility or give internal teams greater control.
Who depends on the platform? Identify the internal teams, customers, members, partners, editors and technical stakeholders involved. A platform serving a marketing team of three has different governance and architectural needs from one serving 40 editors across several regional business units.
Which processes need to change? Websites rarely struggle because of visual design alone. Problems emerge when content creation, approval, publishing, lead handling, support and escalation processes are not redesigned around the new platform.
What would make the project unsuccessful? This question is absent from many RFPs, but it is one of the most revealing. It helps suppliers identify risk and shows whether they can think beyond the immediate build.
A supplier responding thoughtfully to these outcomes is more useful than one that simply repeats your specification back to you.
Describe the Wider Digital Estate
A WordPress website rarely exists in isolation. Your RFP should describe the systems the platform must connect to, exchange data with or replace.
- CRM and marketing automation: Salesforce, HubSpot, Dynamics, Marketo or other systems used to manage leads, customers and campaigns. The direction, timing and quality of data exchange can materially affect build complexity. A requirement for WordPress CRM integration should be described as a workflow, not simply named as a product connection.
- Identity and single sign-on: particularly important for intranets, portals, membership platforms and B2B systems where users need secure authenticated access.
- Ecommerce and payment infrastructure: even apparently light ecommerce requirements can affect hosting, security, compliance, testing and ongoing support.
- Search: whether native WordPress search is sufficient or whether the content volume and user need justify a specialist external search service.
- Data feeds and third-party content: job listings, events, products, publications, stock information, directories and other externally managed data.
- Hosting, DNS and security services: existing managed hosting, Cloudflare configuration, web application firewall rules, domain ownership, backups and infrastructure contracts.
- Analytics, consent and reporting: the tools, governance and data flows that support measurement, compliance and internal reporting.
Suppliers who are not given this information cannot plan or price accurately. Vague integration requirements are a common source of later scope disputes because the supplier has been asked to estimate work without understanding the complete workflow.
Ask How the Supplier Will Manage Technical Risk
This is where an experienced technical partner begins to separate itself from a supplier focused only on delivering pages and features.
A project-focused supplier will tell you what it intends to build. A long-term technical partner should also explain what it is concerned about, what remains unknown and how those risks will be managed.
Your WordPress RFP should ask suppliers to address the following areas.
Legacy content and redirects. How will existing URLs be mapped? Who is responsible for redirect planning and validation? How will search visibility and important inbound links be protected during migration?
Existing integrations and plugin dependencies. Which tools will remain, which may need replacing and how will undocumented or outdated dependencies be investigated?
Data migration. Is content being moved manually, through scripts or through a combination of both? How will migrated data be tested and who owns content sign-off?
Performance and reliability. How will the supplier prevent performance becoming a late-stage optimisation task? Which journeys and functions will be tested under realistic conditions?
Accessibility. Ask how accessibility is embedded across discovery, content, design, development and testing. WCAG 2.2 AA is a useful benchmark for many projects, but the applicable organisational and legal requirements should be confirmed separately.
Security and access. Ask about administrator access, dependency management, deployment controls, vulnerability response, backups and recovery.
Technical unknowns. Give suppliers permission to identify where further investigation is needed. A proposal that acknowledges uncertainty can be more credible than one that gives a fixed answer to everything.
Where the current platform is poorly documented, a WordPress audit may be needed before a reliable rebuild or migration scope can be produced.
Include Content and Editorial Operations
The content management layer is where many WordPress projects begin to struggle after launch. The site is delivered, the CMS is handed over and editors discover that routine updates are confusing, inconsistent or dependent on developer support.
Your RFP should explain how content actually works inside the organisation.
- How many editors will use WordPress, and across which teams, departments or regions?
- Which approval, review and publishing workflows are required?
- Which templates, blocks and page elements must editors control without developer involvement?
- Which content types exist, and how do they relate to each other?
- Are multilingual publishing, localisation or regional variations required?
- What training is needed, and should it include live sessions, written documentation or video guidance?
- Who owns content governance after launch?
A technically sound build can still fail its users if editors cannot manage it confidently. Content operations should therefore influence information architecture, component design, permissions, training and the overall WordPress design and UX approach.
Ask About Life After Launch
Post-launch support is often reduced to one line in an RFP. It should be treated as part of the platform design.
Ask suppliers to explain:
- Warranty and defect liability: what is covered after launch, for how long and how a defect is distinguished from a new request.
- Support model: how issues are raised, prioritised and resolved, and who acts as the main point of contact.
- Monitoring: which aspects of availability, performance, security, errors and business-critical functionality are monitored.
- Hosting ownership: who holds the hosting account and who is responsible for infrastructure decisions, backups and recovery.
- WordPress and plugin updates: how updates are assessed, tested and released, and who responds if an update causes a regression.
- Improvement roadmap: how priorities are reviewed and how the platform continues to evolve after go-live.
- Emergency response: what support is available outside normal working arrangements and which incidents qualify for escalation.
These questions create a shared understanding of the ongoing relationship and help filter out suppliers whose responsibility ends at launch. For an important platform, ongoing WordPress Support & Growth should be considered during procurement rather than added after problems appear.
Avoid Prescribing the Solution Too Early
One of the most counterproductive things an RFP can do is prescribe the complete technical architecture before suppliers have assessed the problem.
Mandating a particular page builder, plugin suite or hosting environment can force suppliers to price a solution that has already been chosen, even when another approach may better suit the organisation’s content, integration, performance and support needs.
There may be valid constraints. Your internal team may already support WordPress. Procurement may require a particular hosting arrangement. Existing integrations may depend on specific technology. State those constraints clearly and explain why they exist.
Then describe the problem in enough detail for suppliers to recommend the right architecture. Include user volumes, content complexity, integrations, security, accessibility, performance expectations and editorial needs, and ask each supplier to justify its proposed approach.
Separate essential requirements from exploratory ideas. This gives experienced suppliers room to contribute expertise rather than simply confirming that they can follow a specification.
How to Evaluate WordPress Proposals
Once the responses arrive, look beyond the headline price and visual portfolio.
Evidence of comparable complexity. Can the supplier demonstrate work involving similar integrations, content scale, governance or technical constraints? Relevant WordPress case studies are more useful than a collection of visually impressive but unrelated websites.
Quality of discovery questions. The questions a supplier asks can reveal more than its prepared answers. Suppliers who probe assumptions, identify missing information and ask how success will be judged are thinking beyond delivery.
Explanation of trade-offs. Strong proposals describe assumptions, exclusions, dependencies and risks. A proposal that agrees to everything without qualification may simply be postponing difficult conversations.
Delivery and governance model. Who leads the work? How are decisions made? How are scope questions handled? What does reporting, testing and sign-off look like?
Long-term ownership. What happens after launch? Can the supplier support, host, improve and safely take responsibility for the platform over time?
Commercial comparability. Check that each price covers the same responsibilities. A lower proposal may exclude migration, content entry, accessibility testing, hosting, project management or support that another supplier has included.
When Discovery Should Come Before the Full Proposal
For some projects, asking for a full fixed proposal before a paid discovery phase is premature.
This is particularly true when:
- Integrations are complex, business-critical or poorly documented.
- Legacy content, data sources and migration volumes are unclear.
- Internal stakeholders have conflicting requirements or priorities.
- The existing platform has been inherited from another supplier and its condition is unknown.
- Technical debt has accumulated without a recent assessment.
- The organisation has not yet agreed the required user journeys or operating model.
In these situations, asking suppliers to price the entire build means asking them to guess. The resulting proposals may be unrealistically low, expensive because of contingency or heavily caveated to protect against unknown scope.
A paid discovery phase can include stakeholder sessions, a technical audit, content and integration mapping, risk assessment and a structured recommendations report. It gives both sides the evidence needed to define scope, responsibilities, budget and delivery phases more accurately.
Where the current website is changing supplier, a structured WordPress site takeover may also be needed to clarify access, ownership, hosting, code and undocumented dependencies before larger commitments are made.
If the project contains several major unknowns, discovery should become the first procurement. The full build scope can follow from its findings.
Before You Send Your WordPress RFP
The strongest WordPress RFPs treat potential suppliers as technical advisers rather than order-takers. They explain the desired outcomes, acknowledge constraints, expose important unknowns and ask difficult questions about risk, governance and life after launch.
If your current brief consists mainly of design references, feature bullet points, a budget and a launch date, pause before issuing it. The quality of the proposals will only ever be as strong as the context suppliers have been given.
Make Do designs and builds complex WordPress websites and connected digital platforms, but we also help organisations assess inherited systems, define integrations and plan the support model needed beyond launch.
Preparing a WordPress brief or RFP? Talk to Make Do about defining the technical, operational and support requirements before suppliers are asked to quote.
