Technical SEO Consultant, Netherlands

ERP-fed catalogs and faceted filters on Dutch webshops

A Dutch webshop or wholesale portal with a deep range can generate far more URLs than it has products. Every filter for brand, size, color, material, price band and delivery option creates a new combination, and sorting or pagination parameters multiply them again. Crawlers can spend most of their attention on these variations while new products wait to be discovered.

The fix is a deliberate rule set rather than blanket blocking:

• Index: a small set of filter pages that match real searches, such as a category plus a brand, with unique titles, introductory text and a self-referencing canonical.
• Crawl but do not index: combinations useful to visitors but with no search demand of their own.
• Keep out of crawlable links: sort orders, view toggles and multi-select combinations, handled so crawlers never meet them.

Catalogs fed from an ERP or PIM add their own issues. Discontinued items may vanish and leave error pages behind, variants may appear as separate thin products, and attributes your buyers filter on may never reach the page template. I trace those problems back to the feed and the import rules, which is where they have to be fixed. If product data is the real bottleneck, my system integration work in the Netherlands looks at the link between ERP and shop, and the ecommerce SEO page covers category strategy.

Dutch and English versions: duplicates, switchers and slugs

Plenty of Dutch companies publish in Dutch and English, and the way a CMS handles two languages decides whether search engines see two clean versions or a muddle. Problems a technical review tends to uncover:

• English pages that still contain Dutch navigation, footer text or product attributes, so the page reads as mixed language.
• Untranslated slugs, leaving an English page at a Dutch URL or the reverse.
• Language switchers that send visitors to the other language's homepage rather than the equivalent page, which also weakens internal links between versions.
• Canonicals on the English version pointing to the Dutch page, telling search engines to ignore it.
• Pages that exist in one language only but still carry hreflang pointing to a missing partner.

Slugs deserve a decision of their own. Dutch uses diacritics in words such as financiële or reëel, and long compounds such as magazijnbeheersysteem. URLs can carry accented characters, but they appear percent-encoded when copied and are easy to mistype, so my default recommendation is plain-letter slugs with hyphens between meaningful parts, applied consistently. Whatever you choose should be written into the CMS so editors do not invent their own rules. Strategic questions about Flanders and other markets belong to my international SEO work from the Netherlands.

Delivery promises, product markup and merchant feeds

Dutch online shoppers are used to quick delivery and clear return terms, and many shops state order cut-off times and delivery days prominently. Those promises belong in structured data and feeds as well as on the page, because search engines can show shipping and return details beside product results when the data is consistent.

The checks I run on product templates:

• Product and offer markup with the euro price including VAT as the consumer sees it, plus availability that follows real stock.
• Shipping details and return policy expressed in markup or set in Google Merchant Center, matching the checkout and terms pages.
• GTINs, brand and variant data passed through from the catalog, so variants group correctly.
• Consistency between markup, the visible page and the product feed, since mismatches can lead to disapproved items or missing rich results.

For B2B shops that show prices only after login or quote on request, the approach changes: markup describes the product without inventing a public price, and indexable pages carry enough specification text to answer a buyer's search. Marketplace listings on platforms such as bol run on their own rules and are outside this review. Structured data can make pages eligible for richer listings, never guaranteed. My schema markup consulting page explains how the model per template is built.

Consent tools, tag managers and page speed

Dutch sites operate under EU privacy rules, with guidance from the Autoriteit Persoonsgegevens, and commercial sites commonly run a consent tool. From a performance view, that tool and the tags it releases are often the heaviest scripts on the page. A webshop may load a consent platform, a tag manager, analytics, several advertising pixels, a review widget, a chat tool, payment badges and a recommendation engine, each added by a different team.

Core Web Vitals field data shows the combined effect on real visitors, split by template and device. I then trace slow interaction or layout shifts to specific scripts:

• A banner that appears late and pushes the page down.
• Tags that fire on every page although they are needed only at checkout.
• Review and chat widgets loading at the start instead of when a visitor needs them.
• Category pages that load a long grid of full-size product images at once.

The output is a tag inventory with an owner for each script and concrete loading changes. Whether a tag may fire before consent, and what the banner must say, are questions for your privacy advisor rather than for SEO. Fast fixed broadband in the Netherlands does not remove the need: many visits come from phones, and interaction delay comes from scripts more than bandwidth. The method is detailed on my Core Web Vitals page.

Replatforming, server logs and working with Dutch agencies

Dutch ecommerce businesses change platforms as they grow: from a hosted starter shop to Shopify or Shopware, from an older Magento build to Adobe Commerce or a headless front end, or onto a B2B portal linked to the ERP. Each move changes URL patterns, templates and the way filters and variants behave. Without a redirect map and staging checks, a shop can lose the visibility of its category pages overnight.

My SEO migration process covers a benchmark of current URLs, a one-to-one redirect map, SEO requirements for the new templates and a crawl of staging before launch, followed by close monitoring.

Server logs help before and after. They show whether crawlers reach new products quickly, how much activity goes to filters and parameters, and whether old URLs are still requested long after a move. Hosting and CDN providers store logs differently; I specify the export and analyze it within your data processing arrangements.

Implementation stays with your development team or agency. I deliver findings as tickets with evidence and a test, join sprint reviews where useful and recheck the live site after release. All of it runs remotely, with meetings in Dutch business hours. For the wider method, read technical SEO; my other work in this market appears on the Netherlands page.