Since 28 June 2025 the rules of the European Accessibility Act apply in the Netherlands. The Authority for Consumers and Markets (ACM) supervises e-commerce services: websites and apps where consumers buy, book or enter into an agreement. Chat and video calling are supervised too.

Small businesses are exempt. If you have fewer than 10 people on staff and an annual turnover of at most 2 million euros, these obligations do not apply. If you are above that, or growing towards it, accessibility belongs on the plan.

• Webshops and booking sites for consumers
• Signing up for subscriptions or services online
• Chat and (video) calls with customers
• Not required: under 10 staff and at most 2 million euros turnover

What the regulator expects

The ACM assesses against WCAG 2.1 at level AA. According to the ACM, WCAG 2.2 AA becomes the new standard during 2026, and it advises building to it already.

It covers the whole customer journey: paying, identification, digital signing and the emails and attachments that come with an order. You also need an accessibility statement on the website and in the app that is easy to find and accessible itself.

A certificate or quality mark is not required. Video, audio and office documents from before 28 June 2025 and archives are exempt.

Where it goes wrong today

In March 2026 the ACM reported that 61 percent of roughly one hundred of the largest Dutch webshops were not digitally accessible. In those shops, ordering with assistive technology failed, for example because of an order button that does not work with the keyboard or an inaccessible CAPTCHA.

These are not edge cases. Unreachable buttons, unclear forms and error messages without explanation hinder every visitor, so they simply cost revenue too.

Checklist for your order journey

Start with the journey that makes money: search, choose a product, add to cart, check out and the confirmation. Walk through those five steps with these questions.

• Can you reach and use everything with only Tab, Enter and the arrow keys?
• Can you always see where the focus is?
• Do buttons, links and fields have a clear name for screen readers?
• Is the contrast of text and buttons sufficient, also on photos?
• Do error messages explain what is wrong and how to fix it?
• Does the page work at 200% zoom without anything disappearing?
• Are payment and the confirmation email accessible too?

If it does not comply (yet)

If your service does not comply yet, the ACM expects a report with a plan. Critical and serious problems are reported within a week, smaller ones within a month, unless you fix them within that period.

Decide who is responsible, publish the accessibility statement and plan the improvements. Accessibility is cheapest when it is part of the design from the start: colours, components and forms that are right from day one. A redesign or rebrand is the ideal moment.

Sources

• ACM: Accessibility of e-commerce and electronic communication services (Dutch)
• ACM: Most large webshops are not accessible to customers with a disability (24 March 2026, Dutch)
• EUR-Lex: Directive (EU) 2019/882, European Accessibility Act
• W3C: Web Content Accessibility Guidelines (WCAG) 2.2

A rebrand is about name, colour and story. Search engines mostly look at addresses, content and links. Forget that layer and you lose pages that brought in visitors and enquiries for years.

So first list every existing URL: from the sitemap, the CMS, server logs and the links report in Search Console. Include images, PDFs and other files people find.

• Which pages bring traffic and enquiries today?
• Which URLs receive links from other websites?
• Which content disappears on purpose?

One old URL, one new destination

Map every old URL to the best matching new page. Google recommends permanent server-side redirects such as 301 or 308, and states that they do not cause a loss in PageRank.

Do not send everything to the homepage. An old service page redirects to the new service page. For content that really disappears, a 404 or 410 is more honest than a redirect to something unrelated.

Avoid chains and point straight to the final destination. Keep redirects for as long as possible, according to Google generally at least a year.

• Permanent server-side redirects (301 or 308)
• No redirect chains
• Internal links straight to the new URL
• Canonical and hreflang updated

Launch day

Check that robots.txt and noindex do not block the new site. Add both the old and the new address to Search Console and submit the new sitemap. If the domain changes, also use the Change of Address tool in Search Console; for new paths only or a switch to https that is not needed.

• robots.txt and noindex checked
• New sitemap submitted
• Spot check: ten old URLs lead to the right page in one step
• Forms, analytics and structured data tested

The first month after

Expect fluctuation. Google calls temporary ranking shifts normal, and for a medium-sized site it can take a few weeks or more before the new URLs show everywhere.

So measure per page instead of only the total: do the most important old URLs get their traffic back on the new addresses? Check 404s and coverage in Search Console every week and fix missed redirects straight away.

Sources

• Google: Site moves with URL changes
• Google: Redirects and Google Search

Google does not describe a separate technical trick for appearing in AI answers. A page still needs to be crawlable, indexable and useful, with content that matches what its markup promises.

That does not make GEO a replacement for SEO. Google treats GEO and AEO as work on the same search experience. The brief does become sharper: publish information that genuinely improves an answer and clearly show who is responsible for it.

For Google, an llms.txt file, special AI markup and artificially chunked text provide no ranking benefit. Such a file may be useful for other systems, but it does not replace a crawlable page with strong content.

• One indexable URL per language
• Clear author and organisation details
• Internal links from relevant services and cases
• Visible content and structured data that say the same thing

Make knowledge verifiable

A generic overview is easy to replace. First-hand observations, concrete choices, local context and demonstrable project experience are not.

Name primary sources when a fact depends on them. Include publication and modification dates and visibly correct outdated information. This helps readers, search engines and AI systems assess provenance.

• Explain what you observed or tested yourself
• Separate facts, experience and opinion
• Link directly to primary documentation
• Update articles when the source changes

Measure meaningful visibility

Do not judge GEO by one isolated prompt. Look at organic traffic, branded searches, relevant landing pages, qualified enquiries and mentions in AI experiences when your measurement platform reports them.

Google now provides a dedicated generative AI performance report in Search Console. Use it as the source for visibility on Google and judge external measurement tools by their transparency, not by a promised secret score.

The best optimisation is still content that is useful without a search engine. If an article does not answer a real question, more schema will not save it.

Sources

• Google: AI features and your website
• Google: optimizing for generative AI features
• Schema.org: BlogPosting

An XML sitemap collects the canonical URLs you want indexed. Keep it clean, provide a credible last modification date and include each language version separately.

A sitemap helps search engines discover pages and understand which URLs you consider important. It does not guarantee that a page will be indexed or receive a particular position.

• Canonical, public URLs only
• A genuine lastmod after a substantive change
• Both Dutch and English pages
• No privacy, test or API routes

IndexNow reports only what changed

IndexNow tells participating search engines that a URL was added, changed or removed. A verification key lives on your domain and you submit only the relevant URLs.

According to the official documentation, an HTTP 200 only confirms that the URL was received. It does not prove that a search engine will crawl, index or rank the page higher.

Use it as a publishing signal, not a ranking hack. Content, internal context and technical quality still determine whether the page has value.

Make publishing a repeatable process

A clean release updates the page, canonicals, hreflang, sitemap and structured data together. You can then signal the changed URL and check its crawl status.

This makes discoverability part of delivery instead of a separate repair round after launch.

Sources

• IndexNow: official documentation
• Google: build and submit a sitemap

Dutch and English pages each belong on a fixed, indexable URL. They use self-referencing canonicals and reciprocal hreflang links to their equivalent version.

That is clearer than replacing text after load based on browser language. Search engines and visitors can then share the exact version they mean.

• Dutch on the root route
• English under /en
• Self-referencing canonicals
• Reciprocal hreflang and an x-default

Suggest, but never lock people in

Country and browser language can help suggest a suitable version on the first visit. The language switch must remain visible and a manual choice should take priority.

Avoid unconditional IP-based redirects. They can send travellers, VPN users and crawlers to the wrong language.

Translate meaning, not just words

A good English version translates navigation, forms, metadata, error messages, structured data and legal explanations too. The message can become natural English as long as facts and project context remain consistent.

Google treats HTML tags, HTTP headers and sitemap hreflang as equivalent methods. Using several methods provides no additional search benefit and only makes sense when they are maintained automatically from the same source.

Test both languages as separate user journeys. A perfect homepage with a half-translated form is not a multilingual website.

Sources

• Google: localized versions of your pages
• Google: managing multi-regional and multilingual sites
• Schema.org: inLanguage

Good structured data starts with a clear page. If a name, service, author or location is vague in the visible content, markup cannot repair it.

Map the real entities and relationships first. Then add a machine-readable layer from the same content source.

Google recommends publishing fewer properties that are complete and accurate. More markup is not automatically better when visible content and JSON-LD do not match.

The most useful building blocks

For a service business, Organization, Person, WebSite, Service, CreativeWork, BlogPosting and BreadcrumbList are usually enough.

• Use stable @id references
• Mark up visible facts only
• Never invent reviews or results
• Validate after every content change

Maintenance creates the value

The best implementation is not the largest graph, but a model that stays correct automatically when a case, author or service changes.

Sources

• Google: intro to structured data
• Google: breadcrumb structured data
• Schema.org: documentation

Variants, summaries and rapid prototypes help a team respond to something concrete sooner. That helps the team make informed decisions sooner.

• Content inventory
• Prototype variants
• Code assistance
• Accessibility checks

Average output is not a direction of your own

Without a clear content and visual direction, speed mostly creates more of the same. Selection, context and responsibility remain human work.

Our boundary

At Olé, AI gets a defined task, a known source and a control point. A polished result is not enough if nobody can explain how it was produced.

NIST guidance emphasises testing, evaluation, documentation and human oversight. That is why every practical AI process needs an owner, a fallback route and a clear point at which a person decides.

Sources

• NIST: AI Risk Management Framework
• NIST: Generative AI Profile

Consistent name, address and contact details form the foundation. A complete business profile, local cases and honest reviews do more than a row of place names in the footer.

Google names relevance, distance and prominence as the three main local factors. You can only influence the first and third through complete business information, useful local context and a reputation that exists beyond your own website.

Write from experience

Show the local question, what you made and which decisions mattered. That is more useful than a generic page where only the place name changes.

• Local cases
• Clear service area
• Business profile
• Internal links to relevant services

Technology remains the foundation

Fast pages, correct canonicals, local structured data and indexable contact information make all content reliably discoverable.

Do not create an almost identical intermediate page for every town. Google explicitly calls such regional funnel pages doorway abuse when they mainly send visitors to the same final destination.

Sources

• Google Business Profile: improve local ranking
• Google Search: spam policies

WordPress can be a good fit for a marketing team with straightforward publishing needs. A product with multiple front ends, complex roles or demanding performance requirements often benefits from a headless setup.

WordPress supports both routes. Its REST API can provide content as JSON to a separate front end, while the official documentation also stresses that a regular WordPress site does not need the API to work well.

Ask these questions first

Who manages the content, which previews are needed and how many systems must use the same information?

• Editorial workflow
• Integrations
• Preview and roles
• Maintenance
• Total cost

Keep technology out of the way

The best CMS is the system editors understand and developers do not have to repair every week.

Sources

• WordPress: REST API handbook
• WordPress: REST API global parameters

A fast first impression, stable layout and immediate response determine whether an interface feels reliable. Performance should never be postponed until the final week of testing.

Budget before effect

Large images, fonts, tracking and WebGL receive a budget in advance. An interaction that slows the primary task is not finished.

• LCP below 2.5 seconds
• INP below 200 milliseconds
• CLS below 0.1
• Test on real mobile hardware

Measure after launch

A lab test is the start. Field data shows how real visitors, devices and connections experience the site.

Assess LCP, INP and CLS at the 75th percentile and separate mobile from desktop. This prevents a fast office device from masking the experience on slower phones.

Sources

• web.dev: Web Vitals