Five SEO “Errors” on My Static Site That Weren’t Errors

I run a small bilingual tutoring site, Intellix Tutoring. It is static HTML built with Jekyll on GitHub Pages: 68 pages, half in English and half in Italian, on a domain registered at the end of May.

This week, I went through Google Search Console and a third-party SEO audit, which between them reported dozens of problems. Almost none of them needed fixing. One "fix" would have made things worse, and the only real issue took a one-line regex.

Here are the five, and how I checked each one.

1. "Page with redirect: Validation failed"

Search Console listed four URLs under "Page with redirect", and the validation I had started in September said Failed:

http://www.intellixtutoring.com/
http://intellixtutoring.com/
https://www.intellixtutoring.com/
https://intellixtutoring.com/it

First check: does each one go straight to the final URL?

for u in http://www.intellixtutoring.com/ http://intellixtutoring.com/ \
         https://www.intellixtutoring.com/ https://intellixtutoring.com/it; do
  echo "== $u"
  curl -sIL "$u" | grep -iE '^(HTTP/|location:)'
done

Each returned a single 301 to the canonical address (HTTPS, no www, trailing slash) and then a 200. That is exactly what you want.

The validation fails because "Validate fix" asks Google to confirm that these URLs no longer redirect. They are supposed to redirect, so it will fail every time. This report is a list of URLs Google won't index because they point somewhere else, not a to-do list.

2. "Discovered – currently not indexed" (39 pages)

This one looked serious: 39 of 68 pages known to Google but never fetched. Before blaming Google, I crawled the site myself with a Googlebot user agent, starting from the home page and the sitemap:

• all 68 sitemap URLs return 200
• no noindex in meta tags or X-Robots-Tag headers
• every page has a self-referencing canonical
• every sitemap URL is linked from at least three other pages, and the deepest is four clicks from the home page
• no internal link points at a redirect or a 404

Nothing technical was blocking those pages. The domain is about four months old and has very few links from other sites, so Google crawls it slowly. "Discovered" means the URL is in Google's queue and hasn't been worth a fetch yet.

The crawl did find one thing worth changing: the home page linked to none of the 26 blog posts. They were reachable only through the blog index. That is a signal problem, not an indexing bug, and it's the kind of thing a crawl shows you and a dashboard doesn't.

What actually helps here: request indexing by hand for the most important URLs (Search Console gives you a small daily quota), link important pages from the pages Google already visits, and earn links from other sites.

3. Rich Results: "Invalid datetime value"

Google's Rich Results Test passed every post: valid Article, Breadcrumb, and Organization items, no errors. It did flag four optional warnings on the article markup:

Invalid datetime value for "datePublished" (optional)
Datetime property "datePublished" is missing a timezone (optional)

and the same two for dateModified. The JSON-LD had plain dates:

"datePublished": "2026-06-04",
"dateModified": "2026-10-12",

Schema.org accepts a plain date there, but Google wants a full datetime with an offset. The fix across all 26 posts was one substitution:

perl -pi -e 's/("date(?:Published|Modified)": ")(\d{4}-\d{2}-\d{2})(")/$1$2T12:00:00+02:00$3/g' \
  blog/*.html it/blog/*.html

Two choices in there are deliberate:

• +02:00, because every date on the site falls in Central European Summer Time. Posts dated after the clocks change on 25 October need +01:00.
• Noon, because I had no record of the actual publishing time, and a midnight timestamp converted to UTC lands on the previous day. Noon keeps the calendar date the same wherever it's read.

Before pushing, I parsed every JSON-LD block on those pages again: 78 blocks, none broken. After the deploy, I fetched a live post to confirm it served the new values.

4. "Person is missing the required property name" (28 errors)

The audit tool reported 28 structured-data errors, one on each blog post and author page. The articles reference the author by ID:

{
  "@type": "BlogPosting",
  "author": { "@id": "https://intellixtutoring.com/#alex" }
}

and a second JSON-LD block on the same page defines that node in full:

{
  "@type": "Person",
  "@id": "https://intellixtutoring.com/#alex",
  "name": "Alex Ćetojević",
  "url": "https://intellixtutoring.com/about/"
}

The tool didn't follow the @id reference, so it saw an author without a name. Google's documentation uses the same @id pattern for authors, and the Rich Results Test reported the article as valid, with no errors.

Every post uses identical markup, so a single test settled it for all 26. An audit tool's error is a prediction of what Google will do. The Rich Results Test is the closest thing to asking Google directly.

5. Sitemap lastmod "doesn't match" the page date

The audit's most convincing finding: on 12 blog pages, the sitemap said 2026-10-07, while the page's dateModified said September. The whole sitemap held only two dates, 34 pages each, which looked like build timestamps.

It wasn't. I maintain the sitemap by hand, so I compared each lastmod with the last commit that touched the page's source file:

git log -1 --format=%ad --date=short -- blog/ib-math-ia-criteria.html

64 of 68 matched exactly. There are only two dates because the whole site was redesigned on 7 October and half the pages changed again on 12 October.

Then I diffed the article text of the flagged posts from before and after 7 October. On the posts I checked, the text was 98 to 99.8 per cent identical: punctuation and one reworded call to action. But the structured data had changed on every one of them, and Google's sitemap documentation says that "an update to the main content, the structured data, or links on the page is generally considered significant."

So a lastmod of 7 October is correct, and a dateModified in September is also correct. One tells crawlers when the page changed. The other tells readers when the article text changed.

The four lastmod values that didn't match git belonged to posts whose only change on 12 October was the teaser line of a related-post card. That's not significant, so 7 October stands.

"Fixing" this would have meant moving 12 lastmod values back to September, which tells Google that 12 redesigned pages hadn't changed, while 39 pages were already waiting to be crawled. That was the one fix that would have made things worse.

What I'd tell myself a week ago

• Read what a Search Console status means before trying to clear it. Some reports are lists, not to-dos.
• Reproduce every audit error with Google's own tool before fixing it.
• On a static site, git history is a good source of truth for lastmod.
• On a new domain, the bottleneck is crawl demand, not markup. The work that matters is links: internal links from the pages Google already visits, and links from other sites.