Nuxt and online store
Rendering set per route, and the shop pages that end up empty
Nuxt lets a project choose a rendering mode per path rather than once for the whole site, which is why a shop built on it is almost never one thing. The catalogue may be prerendered, the search page rendered on request, the basket left entirely to the browser, and none of that is visible from the front of the site. It is visible in the served document, and the served document is the only thing a crawl ever sees.
Why this pairing is its own job
The Nuxt install guide covers the tag, and the online store guide covers what the assistant has to know. What follows is the part that belongs to neither.
- A shop makes fuller use of per route rendering than anything else, because a category listing and a basket have nothing in common. One entry in the route rules switches server rendering off for a path, and nothing on the resulting page says so.
- The material that answers product questions, the sizing table, the materials, the care instructions, arrives through a fetch from your catalogue. Whether those sentences reach the served HTML is decided by the rule on that path rather than by anything in the template.
- Delivery and returns pages are ordinary content and render without anybody thinking about them, so this pairing produces a very particular corpus: the terms are complete and the products are missing. Most shops expect the opposite.
- Data fetched while a page renders travels with the document so the browser does not ask for it twice. It is present, it is not prose, and it is a large part of why a page can look full in a browser and read thin to anything else.
What changes about the install here
<script src="https://cdn.askably.xyz/w.js" data-key="pk_live_YOUR_KEY" defer></script>The tag is the same one on the Nuxt guide. Everything below is about where it goes on a online store site specifically.
One entry in the configuration reaches the basket as well as the catalogue
The script array in the configuration is site level, so the shop, the search page, the basket and the account pages all take the tag from the same line. That is the right default for the selling half of the site and a decision worth making deliberately for the rest of it.
Nothing in the project separates them for you. Product routes and checkout routes are routes of one application built from one configuration, and the tag has no view of which is which.
Registering it in a layout is how you take the checkout back
If you want it off the transactional pages, register it from the layout your selling pages use instead of from the configuration, and give the basket and checkout a layout without it. A layout stays mounted for as long as pages using it are on screen, which is what makes it a safe home for this.
Register it in a layout rather than in a page. A registration made by a page is withdrawn when the visitor navigates away, which leaves the document disagreeing with your source while the widget carries on working, and that disagreement is what makes the next person's debugging slow.
Whether the basket itself should keep it is a real question rather than a formality. Somebody with a full basket asking about a delivery cut off is the most valuable conversation on the site. Somebody two clicks into paying is not asking anything and should not be interrupted.
Verify from the served document, not from the page in front of you
View source rather than opening the inspector. The inspector shows the page after everything has run, which is the reading a shopper gets. The served document is the reading a crawl gets, and on a shop with mixed rendering those two can differ by an entire product description.
Do it once on each kind of page: a category listing, a product page, a policy page. Three checks settle what the corpus can possibly contain, and they take less time than the first argument about why an answer was vague.
Where the answerable material lives
| Delivery, returns and international terms, which render without anyone deciding to | These are ordinary content pages, they carry their own text, and they answer the questions people type with a full basket. On this stack they are usually the strongest part of the corpus, and they are strong by accident rather than by design. |
|---|---|
| Product and category copy, reachable only where the rule on that path allows it | Sizing, materials, compatibility and care instructions come from the catalogue. On a prerendered or server rendered path those sentences are in the document and can be indexed. On a path with server rendering switched off they are not, and no crawl setting recovers them. |
| The serialised state travelling with the page, which is data rather than writing | Whatever a page fetched while rendering is carried in the document so the browser does not request it again. It is machine readable rather than readable, full of identifiers and figures with none of the sentences around them, and it is not a substitute for having the words on the page. |
| Price and availability, which are in the document and true only of that moment | A server rendered product page carries both, so a crawl captures both. Neither is a fact about now. An assistant quoting a price from a page read last month is quoting your site accurately and your shop wrongly, which is the argument for keeping the material at the level that survives a season. |
The first thing to get right
View source on one product URL and search the HTML for a sentence you can read in the browser, such as a line from the care instructions.
It settles the question that decides everything else here, and it settles it in ten seconds. If the sentence is there, the product material is indexable and the rest of the work is ordinary. If it is not, no crawl configuration will find it, and the choice is between changing the rule on that path and accepting an assistant that knows your terms and nothing about what you sell.
The failure that belongs to this combination
An assistant that knows the returns policy by heart and has never seen a product
The install goes cleanly, the crawl finishes, and the answers about cut off times, return windows and duty are precise. Then somebody asks whether a jacket runs small, and it refuses, and it keeps refusing on every product question anybody tries.
The cause is neither the crawl nor the threshold. The catalogue routes were left to the browser, so every product URL returned a document with headings, a price and no description. The corpus is complete and contains no product writing, because none was served.
Diagnose it before launch rather than after, because the repair is a change to a route rule followed by a re-index, and both are easier while nobody is reading the answers yet. One look at the served HTML for one product URL tells you which of two quite different projects you have started.
Before you go live
- The origin the page is served from has to be on the allowlist for that assistant, or nothing renders and the browser console says which origin was refused. An apex domain and its www are two different origins to a browser, so list both, along with any staging or preview host you want it to work on.
- Open the site as a visitor would, on the pages a online store visitor actually lands on, and ask it something only your own material could answer. A widget that renders is not the same as a widget that has read anything.
Questions
- The pages look complete in the browser. Why would a crawl see less?
- Because a browser runs everything and a crawl reads what was sent. On a path where server rendering is off, the shop assembles itself after the document arrives, so the document carries a shell. That is not a limit of the crawl, it is what your site served, and the change is on your side of the wire.
- Should the widget be on the basket and the checkout?
- Keep it on the basket and take it off the checkout. Delivery and returns questions are asked with a full basket and are worth answering there. A visitor entering card details has stopped asking questions, and a launcher over a payment step is a distraction on the one screen where you have already won.
- Can it tell somebody whether an item is in stock?
- No, and this is the pairing where that is easiest to forget, because a server rendered product page genuinely does carry an availability line and the crawl genuinely did read it. What it read was a sentence that was true at the time. Leave live state to the page and keep the material to what does not change weekly.
Keep reading
- Installing on NuxtRegister the loader in nuxt.config under app.head.script, or with useHead in a layout, and set tagPosition so it lands at the end of the body.
- Everything for a online storeDelivery cut-offs, the returns window and restock questions get asked before purchase. The one thing an assistant cannot do is find an order.
- A help centre anybody can read and a request form only account holders can useShoppers can read the delivery article and cannot open a ticket without an account. That makes the handover email the only route to a person.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.