Deploy steps · code layer
To implement SEO in a website, change six things in the code layer: robots.txt, canonical tags, the XML sitemap, structured data, hreflang and 404 handling. Content and links still do the ranking work, but these switches decide whether Google can crawl, merge and trust what you publish. Ship them in a fixed order, then verify each one on the live domain after deploy.
Live-site verification included · Template-level fixes, not page-by-page patching
Implementation means editing files a visitor never sees: a robots.txt that allows the right paths, one canonical URL per topic, a sitemap of indexable pages only, JSON-LD that names the entity, hreflang for real translations, and a 404 route that returns a true 404 status. Verification on the live domain is part of the job, not an afterthought.
01 / why the code layer decides
Googlebot does not experience your page the way a buyer does. It fetches the HTML, reads the status code, follows the redirect chain, checks the canonical, and then decides whether the URL belongs in the index at all. If a staging server answers 200 on a production domain, if every filter combination claims the same canonical, or if the sitemap lists noindexed URLs, a content team can write excellent copy and still get nothing indexed.
The economics are also different down here. One template line fixes four thousand product pages at once; rewriting four thousand product descriptions fixes one page at a time. That asymmetry is the whole argument for implementation order: set the switches first, then pour content into a site that can actually receive it.
02 / what breaks quietly
03 / the switchboard
Treat these as configuration, not content. Each one answers a different question for the crawler, and each fails in a different way. Read the last column first — it is what you will actually see when the switch is wrong.
| Switch | Where it lives | What it decides | Failure symptom |
|---|---|---|---|
| robots | /robots.txt | Which paths may be crawled | Key templates blocked by a legacy rule |
| canonical | link rel=canonical | Which URL represents the topic | Variants compete and none ranks |
| sitemap | /sitemap.xml | Which URLs are offered for discovery | New pages wait weeks to be found |
| schema | JSON-LD in head | What the page is about | Rich results never appear |
| hreflang | link rel=alternate | Which locale serves which market | The wrong language version ranks |
| 404 | Server status code | Whether dead URLs leave the index | Empty pages accumulate as soft 404s |
Write a short file. Allow everything public, disallow admin, cart, internal search and checkout, and never disallow CSS or JavaScript that the page needs to render. Publish it at the domain root, not in a subfolder, and keep one copy per environment.
Every template emits its own canonical from the entity ID, not from the request path. Variants such as colour, sort order or tracking parameters point at the clean URL. Paginated pages canonicalise to themselves, because their items are not all on page one.
Generate the file from the indexable set: status 200, self-canonical, not blocked. Split it by type when it passes a few thousand URLs, add lastmod only when the content really changed, and remove redirects and noindex pages so the file stays a trustworthy signal.
Choose one primary type per template and fill it from the CMS fields the business already maintains: product with offers, article with author, service with provider, organization on the home page. Keep the markup consistent with what a visitor sees.
Each locale lists every other locale plus itself, and every link must be returned by the target page. Add x-default for the selector page. Never point hreflang at a URL whose canonical resolves somewhere else.
Removed products return a 404 or 410 status and a helpful page with search and category links. Permanent moves use a single 301 hop, never a chain. Do not redirect everything to the home page; that is how a site loses topical relevance.
04 / sequence
Order matters because later steps depend on earlier ones. A sitemap built before the canonical rules is a list of the wrong URLs.
05 / verification
A deploy is not finished when the pipeline turns green. It is finished when the live domain answers correctly to a crawler.
06 / traps
We implement on your templates, verify on the live domain, and hand back a release note your developer can keep.
07 / who does what
Most teams can implement these switches; what they lack is a precise specification and a second pair of eyes after release. Technical SEO Services covers the crawl, the template rules and the release QA. If you suspect the current site already has damage, SEO Audit Services maps it URL by URL first, so the rebuild starts from evidence rather than opinion.
A typical engagement runs in four phases: inventory and crawl, switch design, build support during development, then live verification and a thirty-day watch on server logs. You get the specification, the test set, and a short list of what still needs a decision.
08 / scenario
A parts exporter rebuilt its catalogue and lost visibility within a month. The pages were fast and the copy was decent. The problem was structural: a staging rule had shipped to production, the sitemap listed filtered URLs, and every product canonical pointed at its parent category.
The fix took two template changes and one server rule. Robots opened the catalogue, canonicals moved to the product entity, and the sitemap was rebuilt from the indexable set. The lesson is not that SEO is hard; it is that these six switches are invisible until you fetch the page the way a crawler does.
09 / questions
Usually yes for template-level changes. Robots rules, canonicals, sitemap generation and JSON-LD live in templates or server config, so one release applies them to thousands of URLs.
Crawling. Nothing else matters if Googlebot cannot reach the page. Then canonicals, then the sitemap. Schema and hreflang improve understanding, but they cannot rescue a blocked URL.
Crawl-level changes often register within days to a few weeks, depending on revisit rates. Watch server logs for Googlebot hits before judging ranking movement.
No. Only URLs that return 200, are indexable and are self-canonical. Redirects, noindex pages and filter combinations make the file a weaker signal.
Sometimes, through a CMS field or plugin that injects JSON-LD in the head. On a custom build, template output scales better with the product data.
Serve rendered HTML for indexable routes, or prerender them. Confirm canonicals and meta robots appear in the initial HTML, not only after client-side execution.
