Celectric Website Redesign

Phase 1A Submission Pack

HTML version of the latest Celectric_Phase1A_Submission_Pack_Clean.pdf. This page summarizes the completed Phase 1A discovery, sitemap planning, technical planning, and content/data structure definition based on the accepted quotation.

Source VersionClean PDF submission pack
Phase 1A BillingRM 5,000
Primary GoalIndustrial catalog + RFQ platform
Project StagePlanning baseline for implementation
Purpose

This document summarizes the Phase 1A work for the Celectric website redesign project, based on the accepted quotation. Phase 1A focuses on discovery, sitemap planning, technical planning, and content/data structure confirmation. This pack records the Phase 1A outputs, planning baseline, and recommended implementation direction established for the next project phases.

Phase 1A Scope from Quotation
PhaseScopeBilling Amount
Phase 1A Discovery, sitemap, technical planning, content/data structure confirmation RM 5,000
1. Discovery Summary

Agreed direction

The agreed direction is to redesign the Celectric website as an industrial product catalog and enquiry platform, not only as a static company profile website.

Phase 1 website should support

  • product browsing
  • category browsing
  • brand browsing
  • product specification / datasheet access
  • enquiry / RFQ submission
  • future catalog growth around 3,000+ products
  • a lightweight admin system for managing product and content updates

Primary conversion goal

The primary conversion goal for Phase 1 is enquiry / request for quotation, not public ecommerce checkout.

2. Proposed Phase 1 Sitemap

Main public website pages

SectionPurpose
HomeIntroduce Celectric, highlight product categories, brands, and enquiry CTA
ProductsMain product catalog listing and search/filter entry point
Product DetailIndividual product information, specifications, datasheets, and RFQ CTA
CategoriesProduct discovery by category
Category DetailProducts grouped under a selected category
BrandsBrand listing and brand discovery
Brand DetailProducts grouped under a selected brand
Blog / InsightsTechnical articles, updates, and SEO content
Resources / DatasheetsProduct documents, datasheets, manuals, certificates, or related files
AboutCompany profile and credibility information
Contact / Request QuoteGeneral enquiry and RFQ submission
Recommended Top Navigation

Navigation baseline

  • Home
  • Products
  • Categories
  • Brands
  • Blog / Insights
  • About
  • Contact / Request Quote
3. URL and SEO Structure

Stable, SEO-friendly URL rules

Page TypeURL Pattern
Product listing/products
Product detail/products/{product-slug}
Category listing/categories
Category detail/categories/{category-slug}
Brand listing/brands
Brand detail/brands/{brand-slug}
Blog listing/blog or /insights
Blog article/blog/{article-slug} or /insights/{article-slug}
Contact / RFQ/contact or /request-quote

Product canonical rule

Each product should have one stable canonical product detail URL: /products/{product-slug}. A product may appear in multiple categories, but this should not create multiple product detail URLs.

Category pages should link back to the same canonical product page to avoid duplicate-content issues and keep product URLs stable even when category assignments change.

Three-layer product URL / SEO structure

LayerURL ExamplePurposeSEO Rule
Main product page /products/ee650-airvelocity-transmitter Main product detail page for description, brand/category browsing, datasheets, and enquiry CTA Canonical indexable product page
Configurator page with params /products/ee650-airvelocity-transmitter/configure?45793=241952&45794=297497 Shareable configuration state that restores selected option group/value IDs Usually not a separate SEO page; should canonical back to main product or approved model-number page
Direct model-number SEO page /configuration/ee650t2j3l100p1bd5 Clean landing page for important approved configured model numbers searched on Google Can be indexable only for approved important model numbers

Recommended rule: main product pages are the default canonical product URLs. Tracking parameters such as srsltid should not be included in canonical URLs. Low-value or unapproved configuration combinations should not automatically become indexable SEO pages.

4. Content and Data Structure Confirmation

Product

  • product name
  • slug
  • brand
  • one or more categories
  • short summary
  • product description using Markdown format
  • key specifications
  • product images
  • product datasheets / documents
  • import-ready field structure
  • related products linking field
  • publish status / sort order
  • SEO title / SEO description / canonical URL

Category + Brand

  • category/brand name
  • slug
  • description using Markdown format
  • category image/icon or brand logo
  • publish status / sort order
  • SEO title / SEO description

Blog / Insights

  • title / slug / summary
  • article body using Markdown format
  • cover image
  • category / tag fields where needed
  • publish date / status
  • SEO title / SEO description

Documents / Datasheets

  • document title
  • file type / document type
  • related product, brand, or category where applicable
  • public or internal-only access rule where applicable
  • direct download behavior for product-related documents
  • email tracking for blog-related documents where required
  • file storage path
  • publish status

RFQ / Enquiry

  • customer name
  • company name
  • email
  • phone number
  • message / requirement
  • selected product where applicable
  • selected configuration where applicable
  • selected document request where applicable
  • submission date and status
5. Data Relationship Rules

Product and Category

A product can belong to more than one category.

Recommended relationship: products ↔ categories = many-to-many

Product and Brand

A product belongs to one brand by default.

Recommended relationship: product → brand = belongs-to

Product and Documents

A product can have multiple documents such as datasheet, manual, certificate, technical drawing, and brochure.

6. Technical Planning Summary

Recommended architecture

  • Laravel manages admin dashboard, product data, categories, brands, documents, RFQ, and publish control
  • public website pages are generated as static HTML / JSON files during a controlled publish step
  • Cloudflare R2 stores product images, product specification PDFs, and future private documents
  • Cloudflare CDN / static hosting serves the public website
  • RFQ submission, admin management, and configurator data capture remain Laravel-backed dynamic functions

Manual batch publish flow

  1. Admin updates products, categories, brands, blog posts, images, or documents in Laravel.
  2. Changes are saved as draft or pending changes.
  3. The live public website is not changed immediately.
  4. Admin reviews the pending changes.
  5. Admin clicks Publish Static Site when ready.
  6. Laravel generates updated static pages and data files.
  7. The system deploys the generated static files to the public hosting/CDN.
  8. Cache is refreshed or purged where needed.
  9. Admin can review publish status and any errors.
  10. A failed publish should not break the current live website.
  11. The previous successful static version should remain available for rollback where practical.
7. Static vs Dynamic Responsibility Boundary
AreaRecommended Handling
Public homepageStatic generated page
Product listingStatic generated page / static data where practical
Product detailStatic generated page
Category pagesStatic generated page
Brand pagesStatic generated page
Blog / insightsStatic generated page
Admin dashboardLaravel dynamic backend
Product/category/brand managementLaravel dynamic backend
RFQ submissionLaravel dynamic backend
Configurator data captureLaravel dynamic backend
Manual publish controlLaravel dynamic backend / queue job
Publish status trackingPending, building, deployed, failed
Publish failure / rollbackFailed publish should not replace the current live website
File storageCloudflare R2
9. Configurator Scope Confirmation

Included in Phase 1

  • product option groups
  • product option values
  • product option rules
  • all product configurations approved by default
  • browser-based display of generated model / part number
  • shareable configuration URL restore behavior
  • RFQ capture of selected configuration details

Not included in Phase 1

  • full CPQ pricing engine
  • automated quotation calculation
  • inventory validation
  • ERP / Odoo-driven configuration sync
  • public checkout or payment
  • full CPQ-style rule enforcement for future product combinations beyond the launch setup
10. Storage and Document Strategy

Cloudflare R2 is recommended for product images, product specification PDFs, and future private client/order documents.

Storage AreaPurposeAccess Rule
product-images/Product imagesPublic / CDN-friendly
product-specifications/Datasheets, manuals, technical PDFsDirect public download for product-related documents
order-documents/Future invoices, delivery orders, receipts, client filesPrivate/internal business documents
  • Product images should be public/CDN-friendly for fast website loading.
  • Product-related PDFs/documents should support direct download.
  • Blog-related documents may use email tracking where needed.
  • Future order/client documents should remain private/internal where applicable.
11. Admin Scope Confirmation

The lightweight admin dashboard should support:

  • product management
  • category management
  • brand management
  • blog / insights management
  • product image upload
  • product document / datasheet upload
  • document type labels such as datasheet, manual, certificate, wiring diagram, or brochure
  • publish / unpublish control
  • sorting control
  • SEO fields
  • Markdown-based description/body fields
  • manual static publish control
  • publish status review such as pending, building, deployed, or failed
  • RFQ/enquiry review

Long-form content fields should use Markdown format as the source content, not raw WYSIWYG HTML.

12. Phase 1 Baseline Assumptions
  • pricing remains enquiry/RFQ-led in Phase 1, with selective price display possible later if approved
  • Phase 1 is planned as a single-language website unless a bilingual requirement is introduced later
  • WhatsApp or direct sales contact CTA is recommended on relevant enquiry/contact areas
  • Solutions / Industries pages are treated as future/optional content unless specifically requested for Phase 1
  • homepage design should prioritize key product categories and brands
  • product specification PDFs are assumed to support direct download by default
  • email tracking is only applied to blog-related document flows where needed
  • initial document type labels are assumed to include datasheet, manual, certificate, wiring diagram, brochure, and technical drawing
  • additional document types can be added later without changing the overall Phase 1 structure
13. Recommended Next-Phase Focus
  • UI/UX direction and key page layout design
  • frontend foundation for catalog, product, category, brand, and enquiry flows
  • admin foundation for product/content/document management
  • RFQ submission handling and configuration capture
  • static publish workflow setup and deployment readiness
  • preparation and cleanup of the approved launch product dataset
14. Phase 1A Completion Statement

This document records the Phase 1A discovery, sitemap planning, technical planning, and content/data structure definition work completed for the Celectric website redesign project under the accepted quotation.

It serves as the delivery summary for the completed Phase 1A scope and as the working reference for the next implementation stages under the accepted Phase 1 direction.