Technical SEO Consultant, Norway

Engineering sites, document libraries and enterprise CMS branches

Industrial and energy suppliers often carry more value in their documents than in their pages. A buyer searching for a specific valve, winch or cable type may land on a PDF datasheet rather than the product page, which is fine until that PDF is outdated, has no link back to the product or competes with three other copies stored under different paths.

I review document libraries with a few questions in mind:

• Which documents carry search demand on their own, such as manuals and specifications searched by product code
• Whether each PDF has an HTML product page that should be the indexed version, with the PDF linked from it
• Whether old revisions remain live and indexable alongside the current one
• Whether canonical signals for PDFs are set through HTTP headers, since a PDF cannot carry a canonical tag in its content

Enterprise CMS setups add their own issues. Norwegian and English sites are often built as separate content trees, and some pages exist in one branch only. Depending on configuration, a missing translation may fall back to the other language under the new URL, creating duplicate pages in the wrong language. Internal search result pages, preview URLs and print views can also leak into the index. I list each case with the template and setting responsible. The broader audit method is on my technical SEO audit page.

Webshops, ERP data and spare parts catalogs

Norwegian webshops and B2B spare parts portals frequently draw product data from an ERP or PIM. That integration decides much of their technical SEO. A part that is superseded in the ERP may vanish from the store overnight, leaving a dead URL that distributors and old emails still link to. Variants created for each length or voltage can become separate thin pages. Price and stock fields may update in the feed before the page cache refreshes, so markup and visible text disagree.

I agree rules with you and your integration partner:

• Superseded parts redirect to their successor, with the old part number still mentioned on the new page
• Variants that buyers search for separately keep their own URL; the rest are handled as options on one page
• Category filters that match real demand become indexable pages with their own titles; other combinations stay out
• Product markup reads prices including MVA where consumers buy, with availability and part numbers, pulled from one data source shared by the page and the shopping feed

Customer-specific prices on B2B portals deserve care too. Pages behind login are invisible to crawlers, so the public catalog needs enough content to be found while prices stay private. The ecommerce SEO and schema markup pages explain the general approach.

æ, ø and å in URLs, and Bokmål and Nynorsk branches

Norwegian letters in URLs work technically, but only when every system writes them identically. Problems start when the CMS keeps ø in one template, a plugin rewrites it as o in another, and an old agency used oe. Each version can respond with a normal status, so crawlers find several addresses for one page and links split between them.

My review covers the slug rule itself and every place it must be applied: navigation, breadcrumbs, canonical tags, XML sitemaps, hreflang references and the redirect layer. Server logs show which variants crawlers still request. Once the rule is chosen, stray versions redirect permanently to the agreed form and a regression test runs after each release.

Sites that publish in both Bokmål and Nynorsk, typically public bodies or organizations with strong ties to western Norway, need the two versions to behave as distinct pages:

• Separate URLs, each with a self-referencing canonical
• Language codes such as nb and nn applied identically in templates and sitemaps
• A language switch made of real links rather than a script that swaps text on the same URL

Whether you need Nynorsk pages at all, and which markets get which language, is a strategy question covered on my international SEO page for Norway. The point here is that whatever is decided must work identically in every template.

Speed across a long country: coverage, hosting and scripts

Norwegian cities have fast networks, but customers and staff are spread along fjords, islands and mountain valleys, and some read your site from vessels or installations at sea. Coverage there can be weaker, and satellite links are often slower and costlier. Pages tested only on an Oslo office connection can hide problems that a technician in the field meets every day.

I begin with real-user field data from Google, then reproduce failing templates under throttled mobile conditions. Typical causes:

• Large hero images and background video on templates that technical buyers open on a phone
• Product configurators and viewers built as heavy JavaScript bundles, loaded before the specification text
• Consent, chat and analytics scripts competing on load; Norway has tightened its cookie consent rules, and your legal advisor decides what must wait for consent
• Hosting far from Norway or uncached dynamic pages, where a CDN edge in the Nordics and page caching would cut server response

Fixes are ordered by business value, starting with product, service and contact templates. I do not claim speed work moves rankings by itself; it removes friction for the people already trying to read your pages. The Core Web Vitals consulting page describes the diagnosis in detail.

Mergers, migrations, logs and working with your developers

Norwegian business groups regularly acquire competitors, merge brands and fold several websites into one. Each of those moves is an SEO migration: old domains, product URLs and document paths must redirect to their closest equivalents, and the signals earned over many years should follow. I build the redirect inventory from crawls, sitemaps, analytics, backlinks and logs, walk through the new templates on staging and test every redirect, canonical tag and conversion event as the site goes live. The SEO migration page lists the full process.

Server logs are especially useful after a merger. They show whether crawlers still request the retired domain's URLs, whether redirects return the expected status and whether new sections are being fetched at all. Search Console domain properties for each old and new domain complete the picture.

Structured data is worth settling during the same project. Organization markup can carry the legal name and Norwegian organization number as an identifier, with the merged brand's profiles listed consistently, so search engines and AI tools see one entity rather than two.

You keep your developers or agency. I act as the independent reviewer: tickets with acceptance criteria, checks on staging builds and verification after each release, all done remotely in English during the Norwegian working day. See the Norway SEO consultant page for content and local search, the Norway overview for other services, or contact me to scope an audit.