7,387 pages on your website all carry the same recorded timestamp, and your sitemap is handing every one of them to Google.
Your sitemap lists 49 other addresses, the products, pages and categories. That is the first of three findings. The second is a short list of things your site currently tells anyone who asks. The third is that nothing on your site is measuring your visitors, so there is no record of who comes or where they leave. None of the three needs a new website.
Fix 1: the pages you did not add
7,387 posts carry one identical timestamp
CriticalYour sitemap lists 7,388 post addresses and 49 other addresses. Of 800 post addresses we checked, 772, or 96.5%, matched gambling words. Our check missed some gambling words, so it undercounts. We have not established the total number of gambling pages, and we will not put a figure on it that we cannot stand behind.
The identical timestamp is the useful part, because it gives a precise way to list the candidates rather than guess at them. Pages written one at a time through WordPress get different times. Thousands sharing a single second, with a modified date that is not a valid date at all, is consistent with records inserted straight into the database rather than pages posted through your site normally.
When we asked your site for posts dated before that batch, it returned exactly one: hello-world, dated February 3, 2025, the default post WordPress creates when a site is first set up. Asking for posts dated after the batch returned none. So the batch can be listed precisely. Listing is not the same as confirming, which is why the steps in Fix 2 put a review before any deletion.
One caution about those dates. A stored date is a value like any other and can be set to anything, so it records what was written, not necessarily when. We found no posts dated after this batch, but that is not evidence that nothing has happened since, and it says nothing about whether access still exists. Fix 2 is where that question belongs.
They are also being advertised on your behalf. Your sitemap, the file that tells Google what exists on your site, lists all 7,388 posts, every added page among them. Asking Google what it holds for your address returns 13 of these in the first 20 results.
Fix 2: what your site tells anyone who asks
Four things are exposed that do not need to be
HighThese are observations, not conclusions. None of them shows how your site was reached, and we are not going to guess at that. They are simply things visible to anyone that do not need to be.
| What is visible | What we found |
|---|---|
| Account names are published | A public address on your site returns the names admin and web_table. A second address also returns admin. These checks do not establish the full list of accounts or what each can do. |
| The WordPress version is published | Your pages print WordPress 6.8.2, and the readme file loads for anyone. |
| The login page is publicly reachable | It answers on the open internet. Whether it limits repeated attempts was not established by these checks. |
| Your uploads folder lists its contents | It returns a browsable file listing instead of refusing the request. |
Your software is in good shape today, which is worth stating plainly.
| Software | Version | Role |
|---|---|---|
| WordPress | 6.8.2 | core software |
| WooCommerce | 10.1.2 | shop and checkout |
| PayPal for WooCommerce | 2.0.18 | takes payments |
| Contact Form 7 | 6.1.6 | contact form |
We checked each of those against published lists of known weaknesses and found none running a version with a known published problem. That describes today. It says nothing about what was running in April 2025, the date these posts carry, which these checks cannot see.
What to ask your site manager for, in this order. Publishing less is worth doing, but on its own it does not tell you whether someone still has access. That question has to be answered separately, and it is the one that matters most.
- Before changing anything, keep a copy of the site files, the database, and whatever access and login logs your host keeps. Logs are often the only record of how something happened, and many hosts overwrite them within days.
- Restrict access now: change the password on every account that can edit the site, including the hosting login and the database, and sign out all existing sessions.
- Have someone review the full list of accounts and remove any that cannot be accounted for.
- Have someone find how the posts were added and remove anything left behind that would allow it again. Until that is done and checked, treat the site as still reachable.
- Produce the list of posts carrying that 2025-04-11T12:19:00 timestamp, review it, and delete only what is confirmed as not yours. Keep anything uncertain for a second look. Blog posts only; leave products and pages alone. Then ask Google to drop the removed addresses.
- Change the passwords again once cleanup is finished, in case any were captured in between, and watch the post count over the following weeks to confirm it stays where you left it.
- Then reduce what is published: hide the usernames, hide the version, switch off the folder listing, and add a limit on repeated login attempts.
Fix 3: nothing is measuring your visitors
No analytics tag is present on any page we checked
HighWe loaded 7 pages of your shop and looked for the usual ways a site records its visitors. We found none on any of them.
You do still have WooCommerce's own order reports, so you can see orders that completed. What is missing is everything before that: how many people arrived, what they looked at, and where they stopped. If someone puts a doormat in the cart and leaves, there is currently no record that it happened.
This matters more than usual for you right now. Once the added pages in Fix 1 are removed, the natural question is whether it made any difference. Without something recording visitors, that question cannot be answered, and it will not be answerable backwards either. Nothing is being kept today that can be looked at later.
Worth knowing before anyone sets this up: analytics records from the moment it is installed and cannot fill in the past. Whatever gets installed, the sooner it is on, the more of the cleanup you will be able to see the effect of.
What is already in good shape
Three problems is not a verdict on the whole shop, and several things here are done right.
No known-vulnerable versions found
We checked the four pieces of software your site reports against published lists of known weaknesses and found no match.
One frequently targeted address refuses requests
The xmlrpc file returns 403 rather than answering.
The sensitive files we looked for did not open
Config backups, environment files, debug logs and repository files all returned 403 or 404.
Your product pages carry product markup
The product page we checked includes structured product information for search engines.
That is the three.
The video walks through each one on screen so you can see what I am describing, and so whoever manages your site can act on it without me. The main checks are shown above as the commands that produced them, so they can be repeated by anyone you trust.
The added pages are the one to raise today, and the steps in Fix 2 are the part worth passing on word for word. Finding out how they got there matters more than deleting them quickly.
How this was checked, and what it does not cover. Page counts come from your own sitemap files and from WordPress itself. Software versions come from your site's own files. We checked your certificate separately and it is valid, so it is not listed as a problem. The analytics result is from 7 pages; we did not check every page on the site. The search figure is a sample of the first 20 results Google returns for your address, which is a sample rather than a full measure of everything Google holds. Only 3 of the added pages were individually loaded to confirm they still serve; we did not load all 7,388. The gambling share comes from checking 800 page addresses, of which 772 matched; that check undercounts and we have not established a total; the batch was identified by asking your site for posts dated before it, which returned one, and for posts dated after it, which returned none. A separate sample of 1,000 posts found 0 outside the batch timestamp. We did not test any password, did not attempt to sign in, and made no change to your site.