Technical SEO Consultant, Denmark

One backend, several storefronts: Danish multi-store setups

Many Danish webshops sell into Sweden, Norway and Germany from a single commerce backend, using store views, markets or language folders. That keeps operations simple, but it multiplies URLs. The same product can appear in five storefronts, sometimes with untranslated descriptions, sometimes with a canonical tag still pointing to the Danish version, and sometimes reachable through both a market folder and a parameter.

I check each storefront for the patterns that cause trouble:

• Fallback content. A product with no Swedish description shows Danish text on the Swedish URL, creating a duplicate in the wrong language.
• Cross-store canonicals. A template sends every market's canonical to the Danish page, telling search engines to drop the other versions.
• Currency on one URL. Kroner, euros and other currencies swapped by cookie on the same address, so crawlers and shopping feeds see only one price.
• Incomplete hreflang. Language annotations generated for some templates but not for categories or filtered pages, or pointing to redirected URLs.

The fix is usually configuration plus a few template changes, written as tickets for your developers. Which markets deserve their own storefront, and how each should be localized, belongs to market strategy, which you will find on the Denmark international SEO page.

ERP product data and B2B webshops behind login

Danish wholesalers and manufacturers often connect their webshop to Business Central or another ERP that owns items, prices and stock. That link is efficient, and it also produces SEO side effects. When an item is blocked in the ERP, the product page may disappear without a redirect. Variant items created for every size can surface as separate thin pages. Sync delays leave the feed, the page and the markup showing different stock levels.

I trace the flow and agree handling rules with your ERP and web teams:

• Blocked or discontinued items with a successor redirect to it; items without one return a proper not-found or gone status
• Variants that buyers search for individually keep their own URL; others become options on a parent product
• Product markup, the Google Merchant Center feed and the visible page read price and availability from the same source

B2B webshops add a further problem: prices and sometimes whole catalogs sit behind a customer login, and crawlers cannot log in. A public layer of product and category pages, with specifications and the information a buyer needs to request access, lets the catalog be found while agreements stay private. My ERP integration and ecommerce SEO pages explain each side.

Review widgets, consent banners and page weight

Danish sites often carry several third-party widgets on every template: a review platform badge, a consent banner, a chat tool, a newsletter popup and tracking from several ad platforms. Each one adds scripts, and together they can slow loading, delay the response to a tap and push content around as they appear.

Real-user measurements reveal which page types struggle on actual Danish phones and laptops, and lab traces then pin down why:

• Review carousels that load early, shift the layout and fetch more data than the page needs
• Consent banners that become the largest element on mobile or block rendering until their script loads
• Tag managers carrying pixels for campaigns that ended long ago
• Chat and popup scripts that compete with product images on load

Review markup needs its own check. Search engines limit when star ratings can appear, and ratings a business marks up about itself on its own pages are generally not eligible for review rich results; product ratings shown through Merchant Center follow separate rules. I review what is marked up against current guidelines so you do not rely on stars that will never show.

Consent design is a legal decision for your advisor or data protection lead, especially given Danish enforcement interest in cookies. Once that is settled, my job is keeping the banner light and stable. For the wider performance method, read about Core Web Vitals consulting.

Headless and JavaScript storefronts

Some Danish brands have moved to headless commerce, with a JavaScript framework rendering the storefront and the commerce platform working only as an API. Done well, this can be fast and flexible. Done carelessly, it ships pages whose initial HTML holds little more than a script reference.

Google can render JavaScript, but rendering adds delay and points of failure, and many other crawlers, including some that fetch pages for AI answers and link previews, read only the raw HTML. I compare three views of each key template: what the server sends, what a browser renders and what Search Console's URL Inspection reports. Typical findings include:

• Category grids loaded after render, with product links created by click handlers rather than real anchors
• Canonicals and hreflang inserted by script after a default value was already sent
• Removed products that show a not-found message but return a success status
• Infinite scroll with no paginated URLs, so older items are never discovered

Fixes usually involve server-side rendering or static generation for indexable templates, real links and server-side status codes. If you are planning a headless rebuild, involve technical SEO before the framework is chosen rather than after launch. The JavaScript SEO page covers the method in more detail.

Migrations, structured data and working with your agency

Danish companies replatform, merge storefronts and redesign more often than their URL histories can comfortably absorb. Each change needs a redirect map built from crawls, sitemaps, analytics, backlinks and logs, a staging review of the new templates and a launch-day check of redirects, robots rules, canonicals and conversion tracking. The full process is on my SEO migration consulting page.

Structured data is worth tidying during the same project. Organization markup can include your legal name and CVR number as an identifier, with consistent profiles listed, and LocalBusiness markup for shops and showrooms should match each Google Business Profile. Product markup should follow the ERP-driven rules above. The model I use is described under schema markup consulting.

Server logs answer questions no crawler can: whether search engines still request old URLs after a migration, whether filter combinations absorb crawl activity and whether new categories are fetched at all. If your hosting or CDN can export logs, I include them.

You keep your developers or Danish agency. I work alongside them remotely in English as the independent reviewer, writing tickets, checking staging builds and verifying releases during the Danish working day. Danish keyword and local search work lives on the SEO consultant page for Denmark, and the Denmark hub covers ERP and growth services. To scope an audit, get in touch.