Technical specification for a website and online store: structure, template, and example

A technical specification for website development is not a formal document created just for the sake of it. It is a working guide that helps the team design the structure, layout, functionality, admin panel, integrations, SEO, analytics, and acceptance criteria. It helps clarify before the project starts what exactly needs to be created, how the website should work, and by which criteria the result will be considered ready.

When a website specification is written superficially, problems appear during the development process: the personal account was not considered, product import was forgotten, payment logic was not described, the URL structure was not approved, and requirements for SEO, analytics, or the mobile version were not added. As a result, some decisions are made in a hurry, and the budget changes after the project has already started.

At SEO-Evolution, we usually recommend starting not with design, but with the business logic: what the website should sell or explain, where clients should come from, which user actions are target actions, who processes requests, which pages should be promoted in Google, and what will be considered a finished result.

For a simple corporate website, the technical specification can be shorter. For an online store, it should be much more detailed: catalog, product page, cart, checkout, delivery, payment, CRM, inventory accounting, discounts, roles in the admin panel, analytics, SEO, and acceptance criteria. That is why online store development without a proper specification often turns into a chain of clarifications, revisions, and misunderstandings.

Below is a practical logic that can be used to prepare a technical specification for website creation, understand the difference between a specification for a corporate project and an online store, and use a sample technical specification as a basis for your own document.

What is a technical specification for website development

A technical specification for website development is a document that describes the future website from the perspective of the business, user, administrator, developer, SEO specialist, and analyst. It records not only pages and design, but also the logic of forms, catalog, cart, orders, integrations, roles, access rights, analytics events, and acceptance conditions.

A good specification does not simply say make a modern website or add a convenient catalog. Such wording does not help the developer understand the task. Instead, it is necessary to describe which sections are needed, how the user moves through the website, what happens after a request or order, who processes the data, which systems must be connected, and by which criteria the work will be considered completed.

A technical specification for website creation does not necessarily have to be an 80-page document. For a small service website, a structured description with several sections may be enough. For an online store, service portal, or website with personal accounts, the specification should be more detailed, because every unapproved detail can affect the cost and timeline.

Why a specification is needed before development

Before starting website development , a specification removes uncertainty. It does not guarantee that new ideas will not appear during the process, but it gives everyone a shared starting point: what is included in the project, what is not included, which functions are mandatory, and which ones can be moved to the next stage.

For the client, a website development specification is useful for several reasons:

• it becomes clear what exactly they are paying for;

• it is easier to compare proposals from different contractors;

• there is less risk that important features will be remembered only after the budget has been approved;

• it is easier to control the work of developers;

• there is a basis for testing and accepting the finished website;

• it is easier to separate the first launch from future improvements.

For the contractor, the specification is also important. Without it, the project estimate will almost always be approximate. A developer may name an initial price, but after clarifying the functionality, integrations, personal accounts, SEO requirements, payment scenarios, and delivery logic, the estimate can easily change.

Who should prepare the website specification

The best option is to prepare the specification together. The client understands the business, products, customers, internal processes, delivery, payment, and accounting. The development team understands technical limitations, implementation logic, risks, integrations, and dependencies between functions.

If the client writes the website development specification independently, the document often turns out either too general or, on the contrary, overloaded with secondary details. If only the contractor writes the document without diving into the business, important processes may be missed: order processing, different delivery terms, customer groups, product returns, promo codes, and warehouse stock.

At SEO-Evolution, we usually work this way: the business describes its goals, products, customers, and processes, while specialists translate this into page structure, functional requirements, technical limitations, an SEO block, analytics, and acceptance criteria. This way, the website specification becomes not a list of wishes, but a clear work plan.

What to prepare before writing a specification

Before drafting a technical specification, it is useful to collect basic information. This saves time during discussions and helps determine faster what kind of website is actually needed.

• Business description. What the company does, which products or services it sells, which regions it works in, and who its customers are.

• Website goals. Requests, sales, consultations, bookings, registrations, repeat purchases, subscriptions, or support for offline sales.

• Website examples. Not for copying the design, but for understanding the logic: what is convenient, what is not, and which solutions are worth considering.

• Current materials. Logo, brand book, photos, texts, product catalog, price lists, documents, old website, analytics access.

• Limitations. Budget, desired timeline, required integrations, mandatory CMS, accounting specifics, legal requirements.

• Current problems. If a website already exists, it is necessary to understand what exactly does not work: structure, speed, requests, design, SEO, analytics, or admin panel.

Before preparing the specification, it is useful to look not only at competitors, but also at real examples of completed projects. This helps determine faster what is closer to the task: a corporate website, catalog, online store, or service project. For this, you can use the SEO-Evolution portfolio as a reference for different types of implementation.

How to describe requirements correctly in a specification

One of the main mistakes is describing requirements too generally. A developer cannot interpret phrases like make a convenient form or add a proper catalog in one clear way. In a technical specification for website development, every important function should be described through fields, actions, states, results, and exceptions.

A well-written requirement answers simple questions: who performs the action, where exactly it happens, what data is entered, what the system does after that, what the user sees, and what should happen in case of an error.

Structure of a website development specification

The structure of a website development specification depends on the type of project, but the basic sections are almost always repeated. Below is the logic that can be used for a corporate website, service website, catalog, or online store.

1. Project description

In the first section, you need to briefly explain what kind of website is being created and what task it must solve. The project description affects the structure, design, functionality, content, and future promotion.

This block should include:

• website type: corporate website, catalog, online store, portal, service, landing page;

• short business description;

• main products or services;

• geography of work;

• language versions;

• main website goal: requests, sales, bookings, consultations, registrations, subscriptions.

Example for a service website: it is necessary to develop a corporate website for a law firm with separate service pages, a blog, request forms, and the ability to edit content through the admin panel. The main goal of the website is to receive requests from Google, advertising, and direct visits.

Example for an online store: it is necessary to create a website for selling furniture across Ukraine. The catalog must include categories, filters by size, material, color, and price, product pages with photos, specifications, delivery, payment, and quick order functionality.

2. Website goals

Goals are needed for making decisions. A website that should generate service requests and a website that should sell thousands of products require different structures, different designs, and different analytics.

Examples of goals:

• receive requests from organic search and advertising;

• sell products online with payment on the website;

• show the company’s expertise through cases, blog, and service pages;

• reduce the workload on managers through order automation;

• prepare the website for SEO promotion at the development stage.

This is where you should immediately define which user actions will be considered target actions: form submission, phone number click, purchase, adding a product to the cart, registration, consultation request, or newsletter subscription.

3. Target audience

The audience description affects the language of the website, menu structure, filters, design, purchase scenarios, and even the way information is presented. For a B2B website, documents, technical specifications, cooperation terms, and trust in the company are often important. For a B2C store, fast selection, clear pricing, delivery, reviews, photos, payment, and simple checkout matter more.

For a website specification, it is enough to describe 2–4 main user groups:

• who these people or companies are;

• what task they want to solve;

• what matters to them when choosing;

• what objections may appear before submitting a request or making a purchase;

• which devices they use most often.

Example: for an online furniture store, one audience group may look for affordable solutions with delivery across Ukraine, another may need furniture for specific dimensions, and a third may be looking for office products with cashless payment. Each group may require different filters, arguments, trust blocks, and purchase scenarios.

4. Website structure

Website structure is one of the main sections of the specification. Here you need to show which pages and sections will be on the website, how they are connected, and which of them should be landing pages for SEO or advertising.

For a service website, the structure may look like this:

• home page;

• main service pages;

• separate landing pages for directions or cities;

• about the company;

• cases;

• blog;

• contacts;

• service pages: privacy policy, terms of use, 404 page.

For an online store, the structure is usually broader:

• home page;

• product catalog;

• categories and subcategories;

• filter pages, if they are needed for SEO;

• product page;

• cart;

• checkout;

• customer account;

• delivery and payment;

• exchange and returns;

• promotions;

• brands;

• blog or advice section;

• contacts.

It is also useful to add URL examples to the structure right away. For example: /catalog/ , /catalog/mebli/ , /catalog/mebli/stoly/ , /product/nazva-tovaru/ , /delivery/ , /payment/ , /blog/ . This helps the developer, SEO specialist, and content manager understand the future website architecture in the same way.

Google specifically notes that navigation and internal links help it better understand the structure of an eCommerce website, while a logical URL structure makes it easier to crawl pages. That is why the structure of an online store should be approved before design and programming, not after launch. Google documentation on eCommerce site structure clearly shows why this is important at the design stage.

5. Functional requirements for the website

Functional requirements describe what exactly the system must be able to do. This is one of the most important sections, because it has the greatest impact on development complexity.

For a regular website, this block may include the following items:

• request forms;

• clickable phone number on mobile;

• newsletter subscription;

• filtering of services or cases;

• site search;

• multilingual functionality;

• page management through the admin panel;

• uploading documents, photos, or videos.

For each item, it is better to describe not only the name of the function, but also the logic of how it works. For example, a request form: which fields it should contain, which of them are required, where the request is sent, whether an email should be sent to the administrator, and whether the user needs a message after submission.

What to add to the specification for an online store

A specification for an online store has its own specifics. It is not enough to describe pages and design. You need to record how the catalog works, how the buyer adds a product to the cart, how checkout works, how prices and stock are updated, and how the manager processes orders in the admin panel.

Product catalog

The product catalog of an online store should be described through its real structure, not with a general phrase like a catalog is needed. The specification should include:

• categories and subcategories;

• main product characteristics;

• filters and sorting;

• brands or manufacturers;

• product availability;

• variations: size, color, volume, set configuration;

• rules for displaying out-of-stock products;

• rules for generating URLs for categories, filters, and products.

Separately, you need to decide which filter pages should be open for indexing and which should not appear in search. For large stores, this is critical, because filters can generate thousands of technical URLs with no real value for users.

Product page

A product page in an online store should answer the buyer’s main questions before they click the buy button. In the technical specification for an online store, you need to describe which data is displayed on the product page:

• product name;

• article number or SKU;

• brand;

• photos and videos;

• price;

• old price, if there is a discount;

• availability;

• delivery time;

• short and full description;

• characteristics;

• product variations;

• warranty;

• delivery and payment terms;

• reviews;

• similar or related products;

• add-to-cart and quick purchase buttons.

For SEO and product search results, it is also worth adding Product structured data. Google recommends using structured data to better understand product information, price, availability, and reviews. Detailed requirements should be checked in the official Google documentation on Product structured data , because supported properties and requirements may change.

Cart and checkout

The cart in an online store seems like a simple function only at first glance. The specification should describe what exactly the buyer can do:

• add a product to the cart;

• change quantity;

• remove items;

• see the order total;

• see a discount or promo code;

• see the delivery cost, if it can be calculated before checkout;

• return to shopping without losing products in the cart.

Checkout in an online store is better described as a separate scenario: which fields the buyer fills in, whether they can buy without registration, which delivery methods are available, which payment methods are connected, and what happens after the order is confirmed.

Payment and delivery

Payment in an online store should be described not only as connect a payment system. You need to specify which payment methods are required: online card payment, cash on delivery, invoice payment, Apple Pay, Google Pay, installment payment, or payment for legal entities.

For delivery, it is worth describing:

• delivery services;

• cost calculation;

• city and branch selection;

• courier delivery;

• self-pickup;

• restrictions by weight, region, or order amount;

• sending the tracking number to the buyer.

If an online store integration with a delivery or payment system is planned, the specification should record the specific providers, API availability, the person responsible for access keys, and error scenarios: payment failed, delivery unavailable, branch not found, order canceled.

Customer account

A customer account is not always needed at the first stage. If purchases are one-time, checkout without registration may be enough. But if the store has repeat orders, bonuses, purchase history, B2B clients, or personal prices, it is better to describe the account in the specification immediately.

The account may include:

• customer personal data;

• order history;

• order statuses;

• saved delivery addresses;

• wishlist;

• bonus balance;

• repeat previous order.

Admin panel and user roles

The admin panel of an online store should be convenient not for the developer, but for the people who will work with products, orders, customers, and content every day. Access rights should be described before development: who edits products, who sees orders, who changes prices, and who has access only to texts and photos.

Typical user roles in the admin panel:

• administrator;

• content manager;

• order manager;

• marketer;

• SEO specialist;

• accountant or employee who works with payments.

For each role, it is worth defining access rights: who can edit products, who sees orders, who changes prices, who manages discounts, and who has access to website settings.

Product import, export, and synchronization

For a small store, products can be added manually. For a large catalog, this quickly becomes a problem. If there are many products, the specification should describe product import into the online store, product export, and updates of prices, stock, characteristics, and photos.

Separately, you should describe:

• file format: CSV, XLSX, XML, YML, or API;

• update frequency;

• data source;

• what to do with products that are not present in the new file;

• how to handle import errors;

• whether a change log is needed.

If price and stock synchronization with an accounting system is planned, this should not be left for later. Integration of an online store with CRM, 1C, ERP, or warehouse accounting often affects the entire project architecture.

Integrations in the technical specification

Integrations are one of the most common reasons why the budget changes after the start. At the discussion stage, they may sound simple: connect CRM, payment, delivery, and analytics. In development, this turns into specific APIs, access keys, data formats, limitations, errors, and test environments.

CRM should not be left as one line in the style of connect CRM. It is necessary to record which data is transferred, when a lead is created, who sees the request, and what happens if the CRM is temporarily unavailable.

In a technical specification for website or online store development, it is worth describing separately:

• CRM system;

• accounting system;

• payment system;

• delivery services;

• email and SMS services;

• marketplaces;

• Google Merchant Center;

• Google Analytics 4 and Google Tag Manager;

• call tracking or end-to-end analytics systems.

For each integration, you need to specify which data is transferred, in which direction, how often, and what should happen in case of an error. For example, if the CRM is unavailable, the request should not disappear. It should be saved on the website or sent to the manager through another channel.

SEO in the technical specification

SEO at the website development stage is cheaper and easier to consider right away than to rebuild the structure after launch. This is especially important for online stores, where errors with URLs, filters, duplicates, canonical, pagination, and sitemap can create problems even before promotion begins.

In SEO-Evolution projects, we try to approve SEO requirements before development starts: URL structure, meta tags, filter indexing, sitemap, robots.txt, redirects, and analytics. This is cheaper than fixing the same things after launch, when pages have already entered the index.

The specification should include a separate SEO requirements block:

• logical URL structure;

• ability to edit Title, Description, H1;

• human-readable URLs;

• canonical for pages where it is needed;

• robots.txt configuration;

• sitemap.xml for main page types;

• separate sitemaps for products, categories, articles, or language versions if the website is large;

• structured data for organization, breadcrumbs, articles, and products;

• correct 404 pages;

• 301 redirects when old URLs change;

• ability to add SEO texts where they are really needed;

• loading speed and basic Core Web Vitals requirements.

For an online store, SEO requirements must be even more precise: category structure, rules for filter indexing, meta tags for the online store, Title and Description templates for products, Product structured data, sitemaps for products and categories, and the logic of brand pages. Google separately describes the approach to URL structure for eCommerce websites, and these recommendations are better taken into account before launch, not after incorrect pages have already been indexed. Google recommendations on URLs for online stores can be used as one of the references when preparing the specification.

If the website already exists and a redesign or migration is planned, it is worth conducting a technical website audit before development. This helps avoid losing important pages, traffic, redirects, metadata, and the visibility already gained in search.

If the website already exists

A specification for creating a new website and a specification for redesigning or migrating an old website are different documents. If the website is already running, you cannot simply draw a new structure and replace the old one. You need to preserve what already brings traffic, requests, or sales.

Such a specification should include a separate migration block:

• list of important old URLs;

• pages that must be transferred without changing addresses;

• 301 redirect map for pages that will change URLs;

• transfer of Title, Description, H1, and main content;

• checking old pages with traffic in Google Search Console;

• transfer of analytics codes, advertising tags, and events;

• checking robots.txt, sitemap.xml, canonical, and page statuses after launch.

This block is especially important if the website already has organic traffic. A failed redesign may look better visually, but lose some pages, rankings, and requests because of errors in structure, redirects, or indexing.

Analytics and events

Analytics should not be postponed until the website is already launched. If goals, events, and data transfer are not described in the specification, after release it often turns out that purchases, requests, clicks, add-to-cart actions, or checkout stages are not tracked.

For a regular website, you need to define:

• form submissions;

• phone clicks;

• email clicks;

• messenger clicks;

• file downloads;

• visits to thank-you pages;

• events for advertising.

For an online store, eCommerce analytics is needed: product view, add to cart, begin checkout, delivery selection, payment, and purchase. Google describes recommended eCommerce events in GA4 in its documentation, so these events should be planned before programming the cart and checkout. GA4 documentation on eCommerce events helps understand which specific actions should be sent to analytics.

The specification should directly state that analytics must be checked before launch: events fire correctly, there is no duplication, and purchases are sent with the correct amount, currency, products, and order number.

Design, prototypes, and mobile version

In the design section, it is not enough to describe only colors and fonts. It is more important to define which pages need prototypes, which blocks should be present on each page, and which user scenarios need to be planned.

For a service website, prototypes are usually needed for:

• the home page;

• the service page;

• the case study page;

• the blog article page;

• the contacts page.

For an online store, prototypes are also needed for the catalog, category page, product page, cart, checkout, customer account, order page, and payment result page.

A modern specification should also include responsiveness. Google recommends responsive design as the simplest approach to implement and maintain for mobile websites. For business, this is also practical: one URL, one page, and one content logic for different devices. Google recommendations on mobile-first indexing should be considered when approving the design and layout.

Technical website requirements

Technical website requirements should be specific, but the client does not always need to choose the programming language, framework, or database independently. It is often better to describe the expected result, load, integrations, security and support requirements, and agree on the technologies with the development team.

This section may include:

• CMS or framework, if there is a clear requirement;

• hosting or server requirements;

• support for current browser versions;

• responsiveness for mobile devices;

• backups;

• error logging;

• spam protection for forms;

• SSL certificate;

• access control for the admin panel;

• personal data processing;

• the ability to scale the project further.

For projects with authorization, payments, personal accounts, and personal data, security requirements should be described separately. OWASP ASVS can be used as a reference for checking web application security, especially when the website works with user accounts, roles, sessions, and payments. OWASP Application Security Verification Standard provides a structured basis for such requirements.

Accessibility and usability

Accessibility is often left out of the specification, although it affects both users and interface quality. It is not only about people with disabilities. Contrasting text, clear buttons, proper field labels, visible form errors, and keyboard navigation make the website more convenient for everyone.

The specification can include basic requirements:

• sufficient contrast between text and background;

• clear button names;

• labels for form fields;

• error messages next to the relevant fields;

• alt texts for meaningful images;

• the ability to use key elements with a keyboard;

• correct heading hierarchy.

WCAG 2.2 can be used as a reference – these are international W3C recommendations for web content accessibility. The WCAG 2.2 document does not need to be mechanically copied into the specification in full, but its main principles should be considered in design, layout, and testing.

Content and page management

A website technical specification should describe who prepares the content and how it will be managed after launch. Often, the website is already technically ready, but the launch is delayed because of texts, photos, product specifications, legal pages, or translations.

The specification should state:

• who writes the texts;

• who prepares photos and videos;

• which pages must be filled before launch;

• which blocks are edited through the admin panel;

• whether templates are needed for service pages, products, articles, and categories;

• whether multilingual functionality is needed;

• who is responsible for transferring content from the old website.

For an online store, product content is described separately: name, description, characteristics, photos, instructions, certificates, videos, filter attributes, SEO fields, and data for Merchant Center.

Who is responsible for what

Specifications often describe functions but forget about responsible people. Because of this, the launch may be delayed not because of development, but because of missing texts, photos, access credentials, product data, or approvals.

In a technical specification for website creation, it is worth defining:

• who provides the logo, brand book, photos, videos, and texts;

• who prepares the product file or data for import;

• who provides access to the domain, hosting, CRM, payment system, delivery services, Google Analytics, Google Tag Manager, and Search Console;

• who approves the structure, prototypes, design, and functionality;

• who tests the website on the client side;

• who accepts the final result;

• within what timeframes edits and approvals are provided.

This section may seem organizational, but in practice it often saves the project from delays. If the person responsible for content is not defined, the website may be technically ready but still not launched.

Website acceptance criteria

Website acceptance criteria should be described before work begins. Otherwise, at the end of the project, each side may understand differently what it means for the website to be ready.

The specification should define what is checked before launch:

• all approved pages have been created;

• forms work, and requests are sent to the required channels;

• the website opens correctly on mobile devices;

• there are no critical layout errors;

• the admin panel allows editing the required data;

• meta tags, sitemap, and robots.txt are configured;

• analytics is connected;

• redirects from old URLs are configured, if there was an old website;

• basic testing of speed, forms, integrations, and checkout has been completed.

For an online store, testing should include the full buyer journey: product view, filters, adding to cart, promo code, delivery selection, payment, order creation, status change, emails to the buyer and manager, and data transfer to CRM or accounting.

What to include in the first launch and what to leave for the second stage

A website specification should not turn into a list of all ideas that may someday be needed. If you try to launch a complex account system, bonus program, dozens of integrations, marketplaces, email campaigns, and personal prices all at once, the project may stretch over months.

For the first launch of an online store, the critical elements are usually:

• a clear catalog structure;

• categories, product page, cart, and checkout;

• basic payment and delivery;

• admin panel for products and orders;

• SEO basics: URL, meta tags, sitemap, robots.txt, canonical, structured data;

• GA4 analytics and key eCommerce events;

• tested forms, emails, order statuses, and request transfer.

A bonus system, personal prices, complex B2B account, advanced integrations with marketplaces, automated email scenarios, loyalty program, complex product recommendations, and additional advertising mechanics can be moved to the second stage. This division helps launch the website faster and avoid overloading the first release.

Technical specification checklist

Before sending the specification to developers, go through a short checklist. It will help you quickly see which blocks are still missing.

Example of a technical specification for website development

Below is a sample website development specification with a block for an online store. It should not be copied without changes, but it can be used as a basis and adapted for a corporate website, catalog, or eCommerce project.

1. General information

It is necessary to develop an online store for home goods with delivery across Ukraine. At launch, the catalog will include approximately 1,500 products; in the future, up to 10,000. Some products have variations by color, size, and material. Price and stock data are updated from the accounting system.

• Project type: online store with a blog.

• Languages: Ukrainian and Russian at the first stage, English in the second release.

• Sales geography: Ukraine.

• Main goals: online sales, requests, repeat purchases, SEO traffic.

• Key user actions: product view, adding to cart, checkout, payment, consultation request.

2. Website structure

• Home page – / .

• Product catalog – /catalog/ .

• Categories – /catalog/mebli/ .

• Subcategories – /catalog/mebli/stoly/ .

• Product page – /product/nazva-tovaru/ .

• Cart – /cart/ .

• Checkout – /checkout/ .

• Customer account – /account/ .

• Delivery – /delivery/ .

• Payment – /payment/ .

• Exchange and returns – /returns/ .

• Promotions – /sale/ .

• Blog – /blog/ .

• Contacts – /contacts/ .

3. Catalog and products

The catalog must support categories, subcategories, brands, filters, sorting, search, and product pages. Each product should include a name, SKU, brand, photos, price, old price, availability, description, characteristics, variations, SEO fields, similar products, and activity status.

Catalog filters: price, brand, material, color, size, availability, promotion, rating. For each filter, it is necessary to determine whether it creates an indexable page or works only for the user without being opened for search.

If a product is out of stock, the purchase button is not displayed or is replaced with a notify me when available option. Inactive products are not deleted automatically, so as not to create unnecessary 404 pages without an SEO decision.

4. Product page

The product page must include:

• product name;

• SKU;

• photo gallery;

• price and old price;

• availability status;

• product variations;

• characteristics;

• description;

• delivery and payment terms;

• warranty;

• reviews;

• similar products block;

• frequently bought together block;

• Product structured data;

• SEO fields: Title, Description, H1, canonical, URL.

5. Cart and order

The buyer must be able to add a product to the cart, change quantity, remove an item, apply a promo code, choose delivery and payment method. After placing the order, the buyer sees a confirmation page, and the manager receives the order in the admin panel and CRM.

For each order, it is necessary to store the number, date, products, quantity, price, total amount, buyer data, delivery method, payment method, status, and comment.

Order statuses:

• New;

• Confirmed;

• Awaiting payment;

• Paid;

• Sent for delivery;

• Completed;

• Canceled;

• Return.

6. Payment and delivery

Online payment through an approved payment system must be connected. If the payment is successful, the order status changes automatically. If an error occurs, the buyer sees a clear message and can repeat the payment or choose another method.

For delivery, it is necessary to implement city, branch, or courier delivery address selection. Delivery data must be saved in the order and sent to the manager.

7. Admin panel

The administrator must be able to manage products, categories, orders, customers, promo codes, pages, blog, and SEO fields. Separate roles with limited access should be created for managers.

The content manager can edit products, photos, characteristics, and texts, but does not have access to technical website settings. The order manager sees orders and changes their statuses, but does not edit the website structure.

8. SEO requirements

• All main pages must allow editing Title, Description, and H1.

• URLs must be clear and logical.

• Canonical must be implemented for pages where duplicates are possible.

• Sitemap.xml must be created for categories, products, articles, and static pages.

• Robots.txt must be configured.

• BreadcrumbList and Product structured data must be added.

• The 404 page must be designed and return the correct response code.

• When migrating from an old website, a 301 redirect map must be prepared.

For projects that plan promotion after launch, SEO requirements should be approved before programming. Otherwise, part of the work will have to be redone later within website SEO promotion , when errors have already entered the index or started affecting visibility.

9. Analytics

Google Tag Manager and Google Analytics 4 must be installed on the website. For an online store, eCommerce events must be configured: product view, add to cart, begin checkout, delivery selection, purchase. The order amount, currency, products, and transaction number must also be passed.

10. Testing and acceptance

Before launch, the website must be checked in current versions of Chrome, Safari, Firefox, and mobile browsers. Forms, cart, payment, delivery, customer account, admin panel, integrations, SEO fields, sitemap, robots.txt, analytics, and loading speed are tested separately.

Mandatory testing scenarios:

• purchase with online payment;

• purchase with cash on delivery;

• ordering an out-of-stock product;

• applying a promo code;

• payment error;

• repeat payment;

• order status change;

• order transfer to CRM;

• purchase transfer to GA4.

The website is considered ready for launch if all approved pages have been created, the main scenarios work, there are no critical errors, requests and orders are sent to the required channels, and analytics records key events.

What should not be included in the specification

A technical specification for website development should not turn into a chaotic list of all ideas. If some functions are not needed at the first stage, it is better to move them to the second release. This makes it easier to control the budget and launch the website faster.

The main specification should not include:

• functions that do not yet have business logic;

• integrations without access credentials and confirmed connection possibility;

• wishes without a specific use scenario;

• technologies chosen randomly rather than based on the project task;

• excessive design detailing where a prototype is needed first.

A good specification should not describe every pixel. Its task is to remove uncertainty in functionality, structure, data, integrations, SEO, analytics, and work acceptance.

Conclusion

A technical specification for website development is needed by both the developer and the client. It helps turn an idea into a clear work plan: which pages are created, which functions are needed, how the admin panel works, which integrations are connected, and what should be done with SEO, analytics, security, and acceptance.

For an online store, the specification is especially important because an eCommerce project consists not only of design and catalog. It includes products, stock, prices, cart, checkout, delivery, payment, CRM, accounting, analytics, structured data, and manager workflows. If these things are not described before the start, they will almost inevitably appear as additional work.

The best approach is to start not with choosing the design, but with a proper description of the task, structure, functions, and readiness criteria. Then the website is easier to estimate, develop, test, launch, and improve further without constant rework.