Tiandi Netwrap is a manufacturer of bale netwrap, pallet netwrap and plastic mesh-bag products. We built the public website at tiandinetwrap.com as a product-led experience for buyers who need to understand fit, application and next steps before they make an enquiry.
This was not a page-by-page redesign. It was a migration into a maintainable content and route system, with the catalogue, international structure and service-request path treated as one connected information problem.
The diagnosis: a catalogue problem, not a styling problem
The source site exposed company pages, product families, product variants, product knowledge and service routes through a legacy URL structure. The migration inventory also recorded a sitemap endpoint that returned a 500 and a public product-knowledge route that was linked but broken. We used that audit to separate three decisions: which routes should survive, which paths should be canonical, and which links should create discovery.
The resulting architecture follows the buyer’s question. A visitor can move from the baler-netwrap family to a specific TD variant, from pallet netwrap to its application, or from tubular mesh bags to a service request without first learning the manufacturer’s internal categories.
The shipped routes are visible in the live catalogue: baler netwrap, pallet netwrap, tubular mesh bags and the service request route.
One product model, reused across the catalogue
The product experience is built around three families: baler netwrap, pallet netwrap and tubular mesh bags. Variant pages use a shared specification pattern for dimensions, strength ranges and feature lists rather than duplicating a new layout for every SKU. When a spec label, tab or product attribute changes, the interface has one owner instead of a dozen near-identical implementations.
What we delivered. Each family has a distinct route, product details are presented through reusable specification components, and the service request is a deliberate next step rather than a disconnected contact page.
Those are shipped architecture and interface decisions. We are not presenting traffic, lead or revenue improvements here because they were outside the scope of this case study.
The implementation decisions behind the result
Four decisions did most of the work:
- Route ownership. Company, product-family, product-variant, knowledge and service routes each have a clear role. A navigation link is not added just because a source page existed; it has to help a buyer discover the next relevant decision.
- Shared specifications. Reusable product-spec tabs and tables hold the repeated technical pattern. Product copy can vary by family without creating a separate interface for every variant.
- Server-first rendering. Page composition and content stay on the server; client code is reserved for navigation, animation and form interaction. That keeps the catalogue usable before JavaScript finishes loading and limits the amount of behaviour shipped to content-heavy pages.
- One localization source of truth. Locale configuration drives route prefixes, production hostnames, metadata, sitemap entries and hreflang. The language selector and the search signals therefore use the same page identity.
These are not abstract recommendations. They correspond to the delivered Next.js App Router application, its shared product and about-page renderers, the middleware locale resolver, and the sitemap/metadata modules in the production project.
International SEO belongs in the application layer
The production application uses Next.js App Router and is deployed to Cloudflare Workers through OpenNext. Locale resolution happens at the middleware and route layer, not after the page loads in the browser. The live site supports five route locales — English, Russian, French, Spanish and Simplified Chinese — with locale-specific production hostnames where required.
Metadata, canonical URLs, language alternates and sitemap entries are generated from the same locale and route configuration. That closes a common migration failure: a visible language switcher pointing somewhere different from the hreflang or canonical signal.
The content model also preserves the manufacturer’s public operating facts in the right context. For example, the live homepage presents 53 looms and 350 tons of monthly output as company capability evidence; the site treats those as source facts to be maintained, not as agency performance claims.
Product proof before marketing language
The visual system uses the manufacturer’s own production, material and product imagery. The homepage leads with the manufacturing category, then routes visitors into product families, company capability, quality, milestones and service request. The page answers operational questions — what is made, where it fits and how to ask for the right specification — before using generic claims.
Built for the maintenance workflow after launch
Shared renderers own page patterns, locale files own user-facing copy, and targeted client components are reserved for navigation, animation and form interaction. This keeps a multilingual catalogue editable without turning every content change into a component rewrite.
The result is more than a refreshed interface: it is a route system search engines can understand, a catalogue buyers can compare, and a service funnel the team can maintain after launch.
Evidence and limits
The implementation scope is directly observable in the live site and source project: five locale routes, three product families, shared product-detail patterns, a service-request funnel and generated international metadata. We have intentionally left out a before-and-after traffic number because no verified analytics baseline was part of this engagement. That distinction is important: the case proves what was built, not an outcome we cannot substantiate.