Working notes
Does the product data need fixing, or the whole website?
A new website can inherit exactly the same mess. Before replacing the shop, work out whether the problem is the system, the data or the way the two meet.
The short answer
Fix the data first when the catalogue itself is inconsistent. Rebuild the site when the platform or presentation is genuinely the problem. The important bit is finding which layer is actually broken.
Why it matters
A product catalogue can look untidy for several different reasons. The source information may be inconsistent. The import may be mapping it badly. Or the website may be displaying perfectly usable data in the wrong way. Those are different jobs, even when the customer sees the same broken product page.
Start with one awkward product
I'd pick a product that represents the problem and follow it through the process. What does the supplier call it? Which identifier is stored? What does the import change? What does the customer actually see?
That is usually more useful than discussing a complete rebuild before anyone has opened the source file.
Separate the three layers
The source layer contains the information you receive: names, prices, images, specifications and availability. The mapping layer decides how that information becomes products, variations, attributes and categories. The presentation layer decides what appears on the page.
A fix in one layer should not be used to hide an unresolved problem in another. A nicer layout cannot tell you which of two conflicting prices is correct.
Work out what should be kept
Existing product identifiers, useful URLs and reliable descriptions may be worth retaining. A messy export is not proof that everything in the shop is wrong.
In supplier price reconciliation, matching the right records matters more than changing the design. In a variable-product import test, the relationships between products matter before the front end is finished.
Tell me what you need to sort out
If you need this checked or fixed on a real site, send me the URL, a safe example and what you are trying to achieve.
Then choose the size of the job
The answer might be a clean-up, a corrected mapping, a focused piece of code or a migration. Sometimes a rebuild is justified. The point is to reach that decision from the evidence rather than treating it as the default.
My product data work and WooCommerce development overlap for exactly this reason.
HAVE SOMETHING AWKWARD?
Tell me what you need to sort out
Send me the URL, what is happening, what you have already tried and what a useful result would look like. A small anonymised sample is enough to start - do not send passwords, credentials or sensitive customer data.