When running a lean, independent web property, automated audit tools and search engine dashboards can easily induce a sense of panic. For Alex Äetojević, founder of the small bilingual tutoring platform Intellix Tutoring, a routine weekly checkup via Google Search Console and a third-party SEO auditing suite presented a barrage of red flags. The audit reports listed dozens of technical problems across the site, which consists of just 68 static HTML pages split evenly between English and Italian, hosted via Jekyll on GitHub Pages, and built on a domain registered only at the end of May.
However, a systematic investigation into these automated warnings revealed a surprising reality: almost none of them required fixing. In fact, following the advice of one flagged item would have actively harmed the site’s performance in search engine results, while the only genuine issue required nothing more than a simple, one-line regular expression.
The experience highlights a growing disconnect between automated SEO diagnostics and the nuanced realities of modern website management, particularly for static sites built without heavy content management systems.
Untangling "Page with Redirect" Validation Failures
The first major warning flagged by Search Console involved four distinct URLs categorized under "Page with redirect," with a validation process initiated in September marked as failed. The specific URLs listed were the root domain variants with and without the "www" prefix, alongside the Italian language subdirectory path.
For many webmasters, encountering a failed validation on search engine dashboards sparks immediate concern regarding site architecture or broken routing rules. Äetojević decided to bypass the dashboard interface and directly test how the server handled requests to these addresses. By deploying a quick command-line check using the curl utility, he examined the HTTP headers returned by each of the four URLs in question.
The diagnostic test revealed that each address returned a clean, direct 301 permanent redirect pointing precisely to the correct canonical address utilizing secure HTTPS, omitting the "www" prefix, and concluding with a trailing slash, ultimately resulting in a successful 200 OK status response. This behavior represents the textbook standard for domain configuration and canonicalization.
The reason the validation consistently failed in Search Console is rooted in how the dashboard interprets user requests. The "Validate fix" feature prompts Google to confirm that the targeted URLs no longer redirect users elsewhere. Because these specific variations are explicitly designed to redirect traffic to the preferred canonical version, the validation process is structurally guaranteed to fail every time. Rather than representing an actionable to-do list of technical errors, the report merely cataloged URLs that Google deliberately chooses to bypass for indexing because they point toward their proper canonical destinations.
Understanding the Reality of "Discovered – Currently Not Indexed"
Another alarming metric in the Search Console dashboard reported that 39 out of the site’s 68 known pages fell into the "Discovered – currently not indexed" category. To a site owner, seeing more than half of their web pages sitting in limbo without being indexed by a major search engine suggests a severe technical barrier or penalty.
Before assigning blame to search engine algorithms, Äetojević performed an independent crawl of the domain using a simulated Googlebot user agent, initiating the sweep from both the homepage and the XML sitemap. The crawl results confirmed that no technical obstructions, such as misconfigured robots.txt files or restrictive meta tags, were blocking access to those pages.
The underlying explanation for the unindexed pages was far more mundane: domain age and link authority. At roughly four months old and possessing very few inbound links from external websites, the domain naturally experiences a conservative crawl rate from search engine bots. The "Discovered" status simply indicates that the URLs reside within Google’s processing queue and have not yet been prioritized for a full content fetch.
While the diagnostic disproved any technical indexing bugs, the independent crawl did uncover a valuable architectural insight that a dashboard interface would never reveal. The homepage did not feature direct links to any of the 26 published blog posts, meaning those articles were exclusively reachable through the secondary blog index. Addressing this signal issue required simple internal linking adjustments, alongside manually requesting indexing for key URLs via Search Console’s limited daily quota and gradually building organic external references.
Resolving Rich Results and Datetime Value Warnings
Moving on to structured data, Google’s Rich Results Test successfully validated every blog post on the domain, confirming proper markup for Article, Breadcrumb, and Organization items without generating errors. Nevertheless, the test flagged four optional warnings concerning datetime properties within the article markup.
Specifically, the diagnostic tool reported that the optional datePublished and dateModified properties featured invalid datetime values and were missing mandatory timezones. The existing JavaScript Object Notation for Linked Data implementation utilized standard plain date formats. While the broader Schema.org specification accepts plain dates for these fields, Google’s structured data guidelines prefer a complete timestamp accompanied by a specific time offset.
Rather than manually editing dozens of files through a text editor, the issue across all 26 blog posts was resolved efficiently using a single substitution command via Perl, which injected the required time and timezone offset into the publication and modification metadata. Before deploying the update, the JSON-LD blocks across every affected page were parsed to ensure the underlying code remained structurally sound. A subsequent live fetch confirmed that the search engine parser successfully recognized the updated values.
Navigating Complex Author Identification Structures
An external SEO audit tool reported 28 separate structured-data errors, pointing to every individual blog post and author page on the site. The diagnostic tool claimed that the "Person" schema was missing the required name property.
A closer examination of the codebase revealed how the markup was structured. The individual articles referenced the author by a unique identifier string, while a separate JSON-LD block located elsewhere on the same page defined that author node in complete detail, including the full name and profile URL.
The third-party audit tool lacked the capability to follow internal node identifiers across different blocks, leading it to misinterpret the reference and report a missing name. Crucially, Google’s official developer documentation explicitly endorses this exact identifier pattern for author attribution, and Google’s own Rich Results Test verified that the articles were fully valid with zero errors. This instance underscored the practical difference between third-party automated predictions and direct verification through official testing tools.
Evaluating Sitemap Lastmod Discrepancies and Content Significance
The most compelling finding presented by the third-party audit involved the sitemap lastmod tags. The audit noted that on 12 blog pages, the sitemap indicated a modification date of October 7, whereas the internal dateModified metadata inside the page source pointed to September. Furthermore, the entire sitemap contained only two distinct dates, evenly distributed across dozens of pages, giving the initial impression of automated build timestamps rather than accurate update logs.
Investigating the discrepancy through version control history revealed that the sitemap dates were maintained manually and aligned precisely with the git commit logs for 64 out of the 68 pages. The concentration of dates around October 7 and October 12 corresponded directly to site-wide design updates and content refreshes.
A textual diff analysis of the flagged posts demonstrated that the core article text remained between 98 and 99.8 percent identical before and after October 7, with changes limited to punctuation adjustments and minor call-to-action revisions. However, the embedded structured data had been updated across all pages during the redesign. According to search engine sitemap documentation, updates to structured data or internal links are generally considered significant enough to warrant a refreshed modification date.
Consequently, the October 7 lastmod date in the sitemap accurately reflected when technical changes occurred, while the September date inside the article body correctly informed human readers of the last major textual revision. Attempting to "fix" the sitemap by rolling those dates back to September would have communicated inaccurate signals to search engines regarding the freshness of the newly redesigned pages.
Reflecting on the week’s troubleshooting process, the experience served as a reminder that automated dashboards and third-party audits are designed to cast a wide net, flagging potential points of friction rather than providing definitive verdicts. For developers managing lean web properties, separating genuine technical barriers from dashboard noise remains an essential skill in maintaining a healthy, functional site.
Comments (0)