Technical SEO work is easier to commission through a concrete change list: which pages are included, what must change and what will count as evidence of completion. This gives the website owner and developer a shared way to assess the work.
This guide provides a working URL matrix and an acceptance process for a small implementation. Use them independently or as a starting brief for DDRW technical SEO setup. The example is illustrative; it is not a report of a client project.
Record the pages and their starting state
Begin with one existing website and a list of priority URLs. Choose pages that actually present your services or products. For a fixed-scope package, agree on a finite list: “fix the whole website” leaves both the workload and the completion criteria undefined.
For each page, record its current address, HTTP status, page title, canonical URL and indexability rules. An HTTP status is the server’s response code: 200, for example, indicates a successful response, but does not prove that the intended content is present. A canonical identifies the preferred address among duplicate or very similar pages. Add columns for the expected result and evidence of verification.
The content owner should approve service names and the facts used in metadata. If a revised phrase changes the promise made to a customer, it is a content decision that the technical implementer cannot make automatically. Titles and descriptions need accurate information about the offer, rather than a collection of desirable search terms.
Build a change matrix
The table below is an illustrative extract from a service website brief. All paths are examples. In a real document, replace “own URL” with the full preferred address, including the protocol and domain.
| URL or group | Title and description | Canonical | Search accessibility | Response or redirect |
|---|---|---|---|---|
/services/design | Approved service name and description | Own URL | Crawlable, with no indexing prohibition | 200, intended content |
/services/design?source=mail | Match the main page | Main page, if the content is equivalent | Agree on the parameter rule | Verify actual behaviour |
/old-design | New metadata on the destination page | Destination page’s rule | Destination is accessible | Agreed permanent redirect to /services/design |
Page removed without a replacement | No new offer is prepared | No arbitrary replacement | Separate owner decision | Agreed response for a missing page |
This matrix helps expose conflicting rules. A page cannot reasonably be treated as the preferred version while its canonical points to a different article and the brief demands that this exact page appear in search. The decision depends on the content and purpose of the URL. A parameter alone does not establish that a page is a duplicate: it might change the actual product selection or offer.
Choose a meaningful replacement before introducing a redirect. Changes to many addresses require a separate migration plan, covered in our guide to preserving URLs during a redesign.
Separate canonical, sitemap and robots.txt decisions
These controls have different jobs. A canonical helps communicate the preferred version of similar pages. Google describes it as a canonicalization signal, rather than an unconditional instruction to the search engine. Its canonical URL guide also explains why internal links, redirects and the sitemap should point consistently to the chosen addresses.
A sitemap helps search engines discover pages. Compare it with the agreed list: it should include the intended final addresses, rather than accidental legacy paths. However, Google explicitly states that sitemap inclusion does not guarantee crawling or indexing. Saving the file and seeing a page in search results are separate events.
Robots.txt controls a crawler’s access to URLs. It does not protect confidential data and is not a reliable way to remove a page from search. Google may know a URL even when crawling is disallowed. The robots.txt documentation discusses other mechanisms for exclusion, including noindex; the crawler must be able to request a page to read that page-level rule. Private material needs appropriate access control.
Check the server response and page HTML
After implementation, return to the same matrix. Check every agreed address, including legacy URLs in the redirect list. Record the initial status, final address and destination status. A loop or a redirect to an unrelated homepage does not constitute a completed migration.
Next, compare the actual title, meta description, canonical and indexability rules with the brief. Identify where each value came from: the HTML response, an HTTP header or the result of executing JavaScript. For a site with client-side navigation, compare a direct visit with an internal link transition. Both should present the intended page.
Checking only the CMS settings is insufficient. A value may be saved in the editor but missing from the published document because of a template, cache or another setting. The reverse can happen too: a search engine may still display old information after a correct implementation. Establish the actual website state first, then separately monitor how the search engine processes it.
For each check, record the date, URL and observation. “Canonical fixed” is less useful than “the agreed URL contains one canonical with the expected value.” If a result differs from the brief, preserve the observed value and assign someone to resolve it.
Accept the work through a completion record
For a small implementation, use one document with four statuses: completed, needs correction, deferred by agreement and outside scope. Give each issue a specific URL and expected outcome. This distinguishes an omitted agreed task from a new request made after the scope was confirmed.
Keep the following in the acceptance package:
- the starting and final matrices for the agreed URLs;
- the rules and redirects implemented;
- evidence from the verification checks;
- platform limitations and unresolved questions;
- the person responsible for subsequent monitoring in search engine tools.
This record is not a complete SEO audit. It demonstrates an agreed set of changes. Form behaviour, interface accessibility and editor workflows belong to the broader pre-launch website acceptance process.
When the DDRW package fits
The package covers one existing website and up to ten agreed public pages in one content language. It includes metadata, canonical URLs, a sitemap, robots.txt rules within the platform’s controls, up to ten agreed redirects and post-implementation verification. Working access and approved page information are needed before work starts.
A full audit, new pages, articles, website migration and deep performance optimization are assessed separately. Correct settings do not promise a particular ranking or a date of appearance in search. Ordering several units does not automatically expand a single package: its scope needs to be agreed before work begins.
View technical SEO setup in the shop to check the current terms and submit your page list. A useful starting point is a completed matrix showing the current state, intended change and acceptance method.
