Vintage Vogue

Custom Copyright Archive for the Product Catalog

Vintage product photography is an important business asset. A screenshot folder alone does not provide the same traceable evidence as a dated archive of published product pages.

We developed a production archiving system that submits product and key shop pages to the Internet Archive, preserving time stamped references for future documentation.

Two independent archiving queues

To avoid overwhelming the live store, the system separates historical catalog processing from new and updated products.

Backfill queue

• Processes the published catalog overnight.
• Uses a daily capture cap.
• Keeps only a small number of captures in flight.
• Supports gradual archiving without placing excessive load on the store.

Live-product queue

• Prioritizes newly published and updated products.
• Processes eligible URLs on the same day.
• Uses a separate, smaller processing cap.
• Operates independently of the historical backlog.

When a product is unpublished, pending captures are removed from the queue, while completed captures are retained. A monthly process also queues pages older than 30 days for recapture.

Evidence and administration

The custom plugin records the Wayback link, capture time, and language for each completed entry.

The administration interface provides:

• Queue status and processing visibility.
• A view of recent captures.
• CSV export for recordkeeping.
• A workflow designed to support alternative archival destinations, including self-hosted WARC storage or a legal-grade capture service when enabled.

At go-live, the archive queue covered approximately 4,700 products in both German and English, alongside key shop pages. A subsequent repair cleared the failed backlog, bringing permanent failures to zero.

This provided a more structured way to document the catalog and maintain historical references to product listings.

Product Image Watermarking & AVIF Optimization

Protecting product photography required more than applying a watermark to every image on the website. The implementation needed to protect customer-facing product imagery without contaminating the original assets used by shopping feeds.

We implemented a selective image-protection approach.

Watermarked product presentation

Watermarked image variants are used on individual product pages, in the lightbox, and in the gallery strip.

The image URL substitution runs only on single-product pages, allowing the shop grids, original image files, and external shopping feeds to remain clean.

This distinction is important because Google Shopping and marketplace feeds need the original product image rather than a watermarked presentation image.

Optimized image delivery

The watermarked assets are stored as AVIF files, reducing image weight while retaining the intended visual presentation.

Production holds 12,726 watermarked image files, with no missing AVIF versions reported in the project inventory.

One measured example illustrates the improvement:

Original PNG  694 KB

Watermarked AVIF 145 KB

Approximately 79% smaller for this measured image.

The result is a practical balance between image protection, efficient delivery, and compatibility with the store’s product distribution channels.

Cloudflare Security & Origin Firewall Hardening

The store was operating under repeated automated traffic targeting its APIs, language-detection functionality, and common exploit paths. The investigation also documented periods of gateway errors while PHP and database resources were saturated.

We strengthened the existing edge and origin security layers while preserving legitimate access for customers and trusted crawlers.

Cloudflare configuration

The live environment uses Cloudflare Pro with Full (strict) SSL/TLS and an origin certificate. This ensures certificate verification between the browser and Cloudflare, as well as between Cloudflare and the origin server.

We configured and refined:

• Super Bot Fight Mode to challenge automated clients while allowing verified crawlers.
• Custom rules targeting exploit probes, known malicious agents, scraper traffic, and fake add-to-cart floods.
• More narrowly scoped rate limits for abusive cart activity.
• Access controls designed to avoid blocking ordinary shoppers.

An earlier rate limit had locked genuine German and Belgian customers out for an hour, including requests involving a favicon. We refined the approach so the remaining restriction targeted cart abuse and used a two-minute duration.

Origin-level protection

Additional nginx rules deny known abusive addresses targeting the language-detection endpoint.

Generic download tools receive a 403 response, while Meta’s feed crawler is explicitly allowed so catalog synchronization can continue.

The security investigation documented repeated attempts against shop APIs and shell-style paths. It also recorded periods of gateway errors during resource saturation. The available incident evidence did not show a shell actually running on the shop.

Shipping data that disappeared during the incident period was restored, and edge protections remained in place after the storefront returned to HTTP 200 responses.

Cron Reliability & Cache Exclusions

Background tasks are essential to a store that relies on scheduled product feeds, translation workflows, and catalog archiving.

During the engagement, Cloudflare challenged the server’s own cron requests, causing scheduled work to stall for approximately 49 hours.

We addressed this by:

• Creating a dedicated allow rule for the server’s cron traffic.
• Implementing a worker that calls cron using a normal browser user agent.
• Verifying the resumption of scheduled processing.
• Keeping cart, checkout, account, and WordPress administration pages excluded from HTML caching.

WP Rocket remained part of the performance stack, but sensitive transactional pages were kept outside the HTML cache to avoid disrupting personalized shopping and account experiences.

These changes helped restore the scheduled workflows needed by the archive, product feeds, and other background operations.

Multilingual SEO & Crawl Optimization

A multilingual WooCommerce catalog creates additional technical complexity. Product filters, attributes, archive variations, and translated pages can generate large numbers of URLs that provide little additional search value.

During the investigation, the indexed URL count was approximately 110,000–115,000. Many of these URLs involved filters, product attributes, and thin language copies.

We refined the site’s search and indexing structure without removing useful shopping functionality.

Crawl and indexation improvements

We implemented the following changes:

• Routed attribute and filter queries from bots to cleaner page URLs.
• Preserved size-filter functionality for shoppers.
• Removed attribute sitemaps.
• Restricted the product sitemap to German, English, French, Italian, Spanish, and Swedish.
• Kept newer languages out of that product sitemap.
• Corrected the hreflang default to point to the production homepage.
• Changed nested category redirects to resolve in a single redirect.

These changes helped separate useful product discovery for shoppers from unnecessary URL variations being crawled by search engines.

Search performance during the engagement

The investigation recorded changes in indexed URLs and search performance over the engagement period.

Google indexed URLs

Initial investigation 110k–115k

Low point ~40,000

Later recorded count ~96,200 Interpretation

Indexing volume changed during cleanup and subsequent recovery.

The investigation also recorded two search performance samples:

Earlier sample

458 Search clicks

24,647 impressions

Later sample

1,497 Search clicks

92,959 impressions

These are investigation samples rather than a controlled attribution study. They document the search performance observed during the work; they do not establish that any single technical change caused the full increase.

Google Merchant Center & Product Feed Reliability

Vintage Vogue distributes product data through several external channels. Feed failures can affect product availability, advertising, and catalog synchronization even when the storefront itself remains accessible.

During the engagement, the nightly Facebook and Bing feed refresh process stopped working correctly because the first feed in a batch removed callbacks required by the remaining feeds.

We regenerated all four feeds and restored them to a staggered nightly schedule.

We also verified the image handling rules so Google and marketplace feeds continue receiving original product images rather than watermarked variants.

Merchant Center observations

The investigation recorded the following Google Merchant Center figures:

• Approximately 97,996 products in catalog view
• 80,787 Approved products
• 47,215 Merchant clicks in comparison window

The Merchant Center account remained open during the incident period. These figures provide a snapshot of the catalog and activity recorded during the investigation, rather than a claim that every listed product was approved or actively serving.

Translation Cost Control & Database Efficiency

With 14 published language targets and thousands of products, translation lookups were placing unnecessary pressure on the database and paid translation workflow.

Investigations found lookups scanning millions of rows and approximately 930,000 junk strings in the paid queue. These included search leftovers, SKUs, and URLs that did not need translation.

We improved the workflow by:

• Removing approximately 930,000 junk strings from the paid translation queue.
• Keeping Google Translate blocked.
• Routing new text through TranslatePress AI.
• Introducing a hard cap of one million characters per day.

The goal was to reduce unnecessary translation processing, control costs, and keep the translation workflow manageable at catalog scale.

The daily character limit also provides a defined upper bound for the configured translation process.

Storefront, Checkout & Customer Experience Fixes

Security and infrastructure improvements needed to be accompanied by fixes to the customer-facing experience.

We addressed several operational issues identified during the engagement.

Category pages and product information

• Restored category descriptions on archive pages.
• Corrected Italian size-letter translations.
• Hid the VAT line on category grids while retaining it on individual product pages.
• Restored review badges on cached product pages.

Cart and checkout

A white overlay was blocking the mobile add-to-cart experience. We removed the overlay and retested the cart.

A Portuguese DHL label containing broken placeholders was also patched, and the cart was retested following the change.

Customer privacy and forms

A cached contact form was displaying another person’s name. We adjusted the form behavior so it renders as a guest and clears stored fields, preventing the previous cached information from being shown to another visitor.

Email delivery

A four-hour email outage was traced to a staging filter that had been copied into the live theme. The filter was removed on the same day, restoring the intended email behavior.

Page weight and front-end performance

We deployed font subsets and deferred review widgets across product pages.

On one measured page, the raw HTML response decreased from 2.18 MB to 1.44 MB.

Approximately 34% less raw HTML on the measured page.

An image-markup experiment that broke the mobile layout was rolled back the same day. Additional menu-reduction experiments remained on staging rather than being released prematurely.

Custom Returns Management System

The store required a returns workflow that could distinguish between German orders, orders from other EU countries, and orders from outside the EU.

We developed a custom returns plugin that handles these different paths and supports carrier tracking.

Returns functionality

The implemented system includes:

• Different return handling for Germany, the rest of the EU, and non-EU orders.
• DHL and GLS tracking checks.
• Return-window calculations based on calendar days.
• A public returns page.
• An EU withdrawal form included in the same plugin.

The plugin and EU withdrawal form were deployed to production. However, the EU withdrawal form’s activation switch remained off on the live store at the time of reporting.

Staging-Only Pre-Order Development

Alongside the live improvements, we developed and verified additional pre-order functionality on staging.

The staging implementation includes:

• A pre-order shop badge.
• Product sizes that can sell below zero stock.
• A stock report.
• Additional filters in the order list.
• Admin labels that follow the administrator’s profile language.

Customer-facing sentences remain in German so TranslatePress can translate them through the existing multilingual workflow.

These pre-order features were verified on staging only and had not been released to the live shop at the time of reporting.

Keeping these changes separate from production allowed the team to test functionality without introducing unverified behavior into the active store.

Infrastructure Housekeeping & Deployment Safety

The engagement also addressed storage pressure and the safe management of staging environments.

Disk-space recovery

The shared disk had reached approximately 91% utilization on a volume of roughly 1.5 TB.

We performed several housekeeping operations:

• Emergency log truncation freed approximately 290 GB.
• Approximately 10 GB of unused image-accelerator files were removed from production and staging.
• Approximately 860 MB of translation debug logs were disabled and deleted.
• The existing page cache was preserved.

These actions reduced unnecessary storage consumption without indiscriminately removing cached content needed by the live store.

Staging environment safeguards

We also established a server-side workflow for rebuilding staging from production.

Following a copy, the staging environment is configured with customer email, two-factor login, and live payment settings locked down.

This helps reduce the risk of staging activity interfering with production customers, payment processing, or store operations.