The useful starting point
A useful timeline follows the work and its dependencies. Page counts alone leave too much of a WordPress build undefined.
Count unique templates as well as pages
Ten pages may share one structure, or each may require a distinct layout. Record unique templates, repeated sections, dynamic archives, search states, and single-content layouts. Explain whether a page is a static composition or a view of structured content. This gives the team a better basis for estimating than a sitemap alone.
Make functionality explicit
List forms, integrations, commerce, booking, search, filtering, access rules, and any custom calculation or data flow. Identify the source system, required access, data direction, and expected error behaviour. Third-party availability or undocumented constraints can affect feasibility. Review the technically uncertain part before committing to a schedule for the whole build.
Separate ready inputs from pending decisions
A confirmed design does not necessarily mean content, images, mobile rules, or licences are ready. Create a dependency list with an owner for each item and explain what work it blocks. Some tasks can proceed with representative content; others depend on final information. Agree a point at which changed inputs trigger a scope or schedule review.
Agree review ownership and change handling
Name the person who consolidates the agency’s feedback and who has authority to accept a stage. Distinguish a defect against agreed requirements from a new requirement. Both deserve attention, but they may have different cost and scheduling implications. Include time for review and corrections in the working plan. An estimate that assumes immediate approval at every step is fragile.
Plan migration and launch as work
Document content mapping, redirects, domain and hosting access, email and form configuration, analytics decisions, and rollback responsibilities. Confirm who approves the launch and what makes the site ready. Existing websites need an inventory of current URLs before a redirect plan can be completed. Keep staging out of search while still allowing crawlers to read a noindex directive where that is the chosen control.
Define the conditions behind the timeline
A proposal should explain what the estimated schedule assumes: required inputs, access, review turnaround, third-party approvals, and the agreed scope. If one changes, review its effect openly. A deadline can be an important requirement without becoming proof that every dependency is resolved. The useful output is a delivery plan whose assumptions both teams understand.
Practical scope checklist
Use the checklist below to make the estimation conversation specific. Keep unresolved items visible in the proposal and launch-readiness record rather than burying them in messages.
- Pages, unique templates, and dynamic content
- Functionality, integration access, and technical unknowns
- Content and design readiness with named owners
- Approval stages and change process
- Migration map, launch criteria, and rollback owner
- Schedule assumptions written into the proposal
Reference consulted
Google: Block indexing with noindex
This guide provides a practical planning framework. The project’s requirements and agreed responsibilities determine the final approach.
Co-Founder & CEO, Softvole
Agency partnerships and business direction.