Technical specifications for a corporate website: template and checklist

The terms of reference for a corporate website should describe not the color of the buttons, but the boundaries of the project and the method for checking the result. A good SOW captures goals, audiences, page maps, functional scenarios, integrations, content requirements, SEO, speed, security, and acceptance.

Below is a template using which you can prepare a request to contractors and compare their proposals on the same basis. If the project is just being formed, first download the NBM-IT brief, and after the first meeting, turn the answers into technical specifications.

How does a brief differ from a technical specification?

Brief collects background information: about the company, product, audience, competitors, deadlines and budget. It helps the contractor ask the right questions.

Terms of reference records the agreed decision: which pages and scripts are developed, which systems are involved, what is transferred to the customer and by what criteria the result is accepted.

You should not ask the customer to independently describe the future architecture or choose a stack. This is the area of responsibility of the team that performs turnkey corporate website development. The customer knows the business processes and constraints best, and the contractor translates them into design requirements.

Template of technical specifications for a corporate website

Copy the structure below into your working document. Each item must contain a specific solution, a question for clarification, or a note “not included in the current stage.”

1. General information about the project

• Name of the company and project.
• Responsible on the part of the customer and the contractor.
• Reason for development or redesign.
• Target launch date and events to which it is tied.
• Limitations: brand book, CMS, infrastructure, legislation, contracts with suppliers.
• Links to the current website, analytics, CRM, catalogs and documentation.

Bad formulation: “We need a modern selling website.”

Working formulation: “We need to combine five areas of services, lead users to separate landing pages, transfer requests to Bitrix24 and save the search traffic of the old site.”

2. Goals and measurable actions

The technical specification should not promise a position in the search or an arbitrary increase in sales. Record the actions that the site is required to support:

• submitting an application for a specific service;
• request for commercial proposal;
• downloading technical documentation;
• booking a consultation or demonstration;
• search for a product or solution;
• go to the manager's contact;
• subscription to updates;
• review the case before applying.

For each action, specify the analytics event and the page on which it is available.

Target action	Where does it happen?	What do we transfer to analytics or CRM?
Service request	Service page, case, contacts	URL, service, source, UTM, contacts
Download presentation	Solution page	File name, page, source
Request a quote	Calculator or form	Selected options, budget range, contacts

3. Audiences and user scenarios

Describe not the abstract age of the client, but his task and selection criteria.

Example for a B2B site:

• the manager is looking for a contractor and comparing experience, deadlines and responsibility;
• a specialist checks technical compatibility and documentation;
• the buyer requests an estimate and details;
• the candidate evaluates the team and vacancies;
• An existing client is looking for support and contacts.

For each role, include the starting page, required information, target action, and possible objection.

4. Page map

The map should contain the future URL, the purpose of the page, the main intent and the source of the content.

URL	Purpose	Basic user question	Content owner
/	Company positioning	How are you useful and where to go next?	Marketing
/services/...	Commercial landing	What is included, how much does it cost, what cases are there?	Head of department
/cases/...	Proof of experience	How did you solve a similar problem?	Account + expert
/about	Trust	Who is responsible for the project and how is the company structured?	Head

You can check the finished partition logic with our guide to corporate website structure.

5. Requirements for prototypes and design

Commit:

• list of unique page templates;
• permissions and status of the adaptive version;
• required components: tables, forms, filters, cards, documents;
• download states, errors, empty results and successful submission;
• use of brand book, fonts, photos and illustrations;
• coordination rules and number of iterations;
• Accessibility requirements: contrast, keyboard navigation, field labels, and alternative text.

There is no need to list the coordinates of each element. The technical specification defines the system and scenarios, and the layouts fix the visual solution.

6. CMS and content management

List the entities that the editor should change without the developer:

• pages and blocks;
• services and industries;
• cases;
• employees;
• articles and categories;
• documents;
• SEO fields;
• menu, contacts and forms;
• redirects.

For each entity, specify required fields, role rights, drafts, preview, and change history. If the content comes from 1C, PIM or CRM, determine which system is the source of truth.

7. Forms and integrations

For each form, record the fields, validation, consent to data processing, success message, and application route.

For integration please describe:

• direction of exchange;
• data composition;
• start event;
• authorization method;
• acceptable delay;
• repeat on error;
• logging;
• responsible for access;
• test environment.

The phrase “integrate with CRM” is not enough. The working requirement looks like this: “After a successful submission, create a lead in the X funnel, transfer the service, URL, UTM and contacts; If there is an error, save the application and notify the person responsible.”

8. SEO requirements before launch

SEO cannot be added after the finished design with one line “install plugin”. In the technical specifications include:

• map of intentions and landing pages;
• rules for forming title, description and H1;
• human-readable URLs;
• canonical;
• robots.txt and sitemap.xml;
• bread crumbs;
• editable Open Graph fields;
• structured data corresponding to visible content;
• internal links between services, cases and articles;
• HTML text for important information;
• 301 redirects from old URLs;
• control of answers 200, 301, 404 and 410;
• connecting Yandex Webmaster and Google Search Console.

For the redesign, attach a table “old URL → new URL → action.” Pages with traffic cannot be deleted just because they are not in the new menu.

9. Speed, mobile version and page quality

Instead of requiring “100 PageSpeed points,” capture custom metrics and measurement conditions. As a benchmark for Core Web Vitals, Google uses LCP up to 2.5 seconds, INP up to 200 ms, and CLS up to 0.1 for at least 75% of visits.

In the TOR please indicate:

• priority devices and browsers;
• acceptable weight of key images;
• adaptive image loading;
• rules for connecting fonts and third-party scripts;
• testing environment;
• collection of real field data after launch.

One laboratory test does not guarantee the same speed for all visitors. Therefore, after the release, monitoring of real experience is needed, and not just a screenshot of the report.

10. Security and personal data

Minimum list:

• HTTPS;
• differentiation of rights in the CMS;
• two-factor authentication for administrators, if supported;
• backups and recovery verification;
• updating CMS and dependencies;
• protecting forms from spam and abuse;
• storing secrets outside the repository;
• error logging;
• personal data processing policy;
• list of external services receiving data.

Requirements vary by country, industry, and data type. Legal language must be reviewed by a subject matter expert, and the technical team must implement agreed upon restrictions.

11. Content and migration

For each page, define:

• who provides the invoice;
• who writes and approves the text;
• who prepares photographs and graphics;
• what documents are being transferred;
• what content is archived;
• who is responsible for the final check.

When migrating, keep metadata, URLs, images, documents, publication dates, and attribution separately. Automatic transfer without editorial review often transfers duplicates, old markup and broken links.

12. Analytics

Create a table of events before developing the interface:

• submitting each form;
• form error;
• click on phone, email and messenger;
• downloading a document;
• using a filter or calculator;
• transition to case;
• viewing the key block;
• source and UTM parameters.

Specify the analytics systems, tag container, access rules, and data storage period. The event must have a clear name and parameters so that six months later the report can be read without the author of the setting.

13. Acceptance and transfer of the project

Acceptance must be based on verifiable criteria:

• the pages correspond to the approved map;
• forms create applications in the required system;
• CMS roles have consistent rights;
• mobile scripts work at target resolutions;
• there are no critical errors in the console and server log;
• redirects, canonical, sitemap and robots.txt are configured;
• events come to analytics;
• accesses, repository, instructions and backup copy are transferred;
• The period of warranty fixes and the support format have been agreed upon.

The wording “the customer must like the site” is not an acceptance criterion. The visual part is accepted according to approved layouts, the functional part - according to scenarios and tests.

What is often forgotten to include in technical specifications

1. Empty directory and search states.
2. Errors in external integrations.
3. 404 page and removal rules.
4. Web forms after blocking cookies.
5. Migration of old URLs.
6. Content owner after launch.
7. Licenses for fonts, images, CMS and plugins.
8. Test data and test environment.
9. Availability and error monitoring.
10. Limits of warranty support.

Short checklist for requesting a commercial proposal

Before sending to the contractor, please include:

• description of the company and products;
• reasons for launching a new website;
• list of audiences and target actions;
• preliminary map of sections;
• required functionality;
• list of integrations and technical specialist contact;
• link to the brand book and source materials;
• CMS requirements;
• old analytics and list of important URLs;
• desired time frame and budget range;
• approval procedure;
• contractor selection criteria.

The same package of source data helps to compare not random totals, but the scope of work, risks and responsibilities. Before choosing a command, parsing is also useful how to choose a contractor for website development.

FAQ

Who should write technical specifications for the site?

It is better to prepare technical specifications together. The customer provides the objectives, processes, constraints and billing, and the contractor designs the scenarios, architecture, integrations and acceptance criteria. If the contractor asks the customer to independently select technologies and describe the API, the risk of error is transferred to the wrong side.

Is it possible to evaluate a website without a ready-made technical specification?

You can give a range after a brief and a short meeting. A fixed estimate is possible only after agreeing on the boundaries: the number of templates, functions, integrations, content and migration requirements.

How detailed should the technical specification be?

So much so that the two parties equally understand the result and how to verify it. For a small enterprise site this might be 15-30 pages along with a map and prototypes, while a portal would require separate documentation on roles, data and integrations.

Is it necessary to indicate the CMS in the terms of reference?

If a CMS is already required due to the infrastructure or competencies of the customer team, this needs to be recorded. In other cases, it is better to describe the requirements for content management, security and integrations, and justify the choice of platform after analysis.

Is the prototype part of the technical specifications?

Yes, the prototype clarifies the block layout, scenarios and interface states. The text part fixes rules and boundaries that cannot be clearly shown on the screen.

What if requirements change during development?

Use an agreed change request process: describe the change, assess the impact on time and budget, make a decision and update the documentation. This is safer than verbal agreements in correspondence.

Sources

• Google Search Central: Page Usability Guidelines
• Google Search Central: Search Engine Optimization Basics
• web.dev: Core Web Vitals
• W3C: Web Content Accessibility Guidelines 2.2