The Search Console audit at iEducação began with a decision: separate technical failures from intentional exclusions. The report showed 9,073 non-indexed URLs, but that did not mean there were 9,073 errors to eliminate.
The work connected the reports to the actual WordPress configuration: indexing, redirects, pagination, structured data, and components that affect the browsing experience. The sequence below explains what was done and why each step came before the next.
The source is the technical report provided by the person responsible for iEducação.
1. Record the starting point before changing the site
- Confirm the HTTPS property and the reports’ last updated dates.
- Export examples and cross-check the URLs against the WordPress inventory.
- Record directives, backups, and hashes before changing settings.
The first step was to verify the correct HTTPS property and the data dates. The indexing report was last updated October 23; the Core Web Vitals report, November 3. This reference made it possible to compare Google’s historical data with the site’s current responses.
The available tables were exported and cross-checked against the WordPress inventory: 418 posts, 24 pages, and 293 PDF-type content items, totaling 735 published items. Individual Rank Math directives, categories, sitemaps, and shared components were also reviewed.
Before making changes, backups were created and hashes calculated. Hashes are identifiers that help detect content changes. The implementation compared the previous state to protect concurrent edits. This preparation defined both the scope of the fixes and a way to roll back specific changes.
2. Define what should appear on Google
Eligible for search
The URLs were then classified by purpose. Posts, pages, and categories could be eligible for search, subject to their individual settings. Author profiles with biographies and publications retained their editorial context; empty profiles received a noindex directive to keep them out of search results.
Intentional exclusions
PDF access pages, tags, internal searches, and feeds were to remain accessible to readers but stay out of the index. This is a project-specific policy. Another site may have tag archives or documents that deserve indexing; the decision depends on each address’s content and function.
The alternate canonical group contained URLs that designated another version as preferred. Of the 1,000 exportable examples, 999 had parameters. The decision was to preserve the consolidation of those variants and investigate separately any pagination that actually changed the content.
3. Align robots.txt and noindex
The clearest conflict involved 24 indexed URLs blocked by robots.txt. These were feeds and internal searches. The intent was to exclude them from search, but the block prevented Google from accessing the response and reading noindex.
The fix was to allow crawling of those public routes while keeping the exclusion directive, either in the meta tag or the HTTP header, depending on the document. Robots.txt continued to restrict crawling of the administration area, with the necessary exception for admin-ajax.php. Public images remained crawlable.
There were also differences between the physical file, the Rank Math configuration, and a cached copy in Cloudflare. These sources were aligned and the URL’s cache was selectively invalidated. A robots.txt recrawl was then requested.
In WordPress, the noindex policy was reinforced for the 293 PDF-type content items. Two individual Rank Math exceptions were corrected. Office documents and PDFs served by the site itself received an X-Robots-Tag rule; files hosted on Drive remain subject to the service delivering them.
1. Allow crawling: unblock the public route Google needs to read.
2. Serve noindex: check the response’s meta tag or HTTP header.
3. Monitor exclusion: request a recrawl and watch processing in Search Console.
To apply this procedure on another site, consult Google’s noindex documentation: the crawler must be able to access the page to read the directive. Allowing crawling and allowing indexing are different decisions.
4. Fix pagination and restore equivalent paths
In the /pdf-gratuito/ collection, GenerateBlocks uses the query-a66c71a4-page parameter to change the materials displayed. The second page contains different content from the first. The canonical filter was therefore updated to recognize the actual query and pagination limits.
A valid page retains its own canonical address. A campaign parameter such as utm_source is removed from the canonical when it does not change the content. Invalid or out-of-range values receive noindex. Existing individual canonical settings in Rank Math were preserved.
For the old paths, 28 exact 301 redirect rules were created. The former category page 1 points to the current collection; subsequent pages point to the corresponding position. For example, /categoria/pdf-gratuito/page/7/ leads to /pdf-gratuito/?query-a66c71a4-page=7.
Legacy AMP addresses were handled according to whether an equivalent published post or page existed. Removed routes without equivalents continued to return 404 or 410. The criterion was to restore a real relationship between source and destination, avoiding blanket redirects to the homepage.
5. Check sitemaps and public responses
With the policy defined, the sitemap, the URL map supplied to search engines, was checked against the inventory. It contained 457 URLs: 418 posts, 25 page sitemap entries including the homepage, and 14 categories. PDF-type content items were excluded.
The public check covered those 457 URLs, the 293 PDF pages, and 12 additional addresses, totaling 762 checks. The 28 new redirects were reviewed separately. This kept the expectations for each group clear: access and eligibility, access with exclusion, or redirection.
The 66 historical server error examples were also tested. Since no 5xx error was reproduced, validation was requested for that specific issue. The technical address /wp-*.php, which returned 403, retained its protection.
6. Fix structured data using real information
In the video markup, four objects were missing the thumbnail address, the thumbnailUrl field, and two had date issues. The metadata of the actual YouTube videos was checked, and six VideoObject objects received matching thumbnails, specific titles, and original dates in ISO 8601 format with a time zone.
The date used was each video’s first publication date, according to the source, rather than the maintenance date. The procedure followed Google’s video structured data requirements. The pages’ commercial content was preserved.
The separate video indexing report was interpreted according to the pages’ purpose: the videos supported articles. Artificial watch pages were not created just to change that indicator.
For comments, the prior removal of incorrect microdata was checked, keeping the text visible. Validation of the warnings was requested to reprocess that correction. The mechanism creating assumed sameAs equivalences between tags and Wikipedia pages was also removed.
7. Adjust shared ads and JavaScript
The user experience investigation focused on shared components. The field history showed issues with INP, which measures responsiveness to interactions, and CLS, which measures visual shifts. Late ad insertions, height changes, and a block refreshing every ten seconds were observed.
Automatic refreshing was removed while preserving the initial display. Space was reserved for ads, and the navigation sequence was retained: contextual paragraph, ad, and PDF request button. Ad Inserter’s native integration took control of two download blocks in shared content processing, avoiding duplicates.
Reserving space required checking dimensions after rendering: AdSense applied height styles that overrode a simple min-height solution. Shared containers and responsive rules were adjusted without hiding or cropping ads.
An intermediate attempt using an HTML buffer did not insert the download ad correctly and was reverted. The final solution used the native adinserter() function. Separating that attempt from the final version was necessary to compare the performance of a functionally complete page.
The footer arrival detector also changed: repeated checks during scrolling were replaced with IntersectionObserver, preserving the existing event, its one-time execution, and a fallback with a passive listener. The adjustments remained in the child theme’s shared files.
8. Verify the implementation and start Search Console validations
- Open pages while signed out and check the HTML and HTTP headers.
- Compare canonical and noindex with the policy for each URL type.
- Check ads, buttons, and pagination on desktop and mobile.
- Record final measurements and request validation of the fixed issues.
In the iEducação intervention, this check covered desktop and a 390 px mobile width. The WordPress cache was cleared, along with selective Cloudflare cache entries for changed resources.
Final PageSpeed measurements were recorded for the alphabet letters article and the Educação Infantil category, on mobile and desktop. The intermediate run with an incomplete ad remained identified in the history, separate from the final comparison.
Finally, 11 validations were started: two for indexing, three for video structured data, two for comment warnings, and four Core Web Vitals groups. The robots.txt recrawl request was recorded separately. No individual indexing requests were submitted during this intervention.
What was verified and what to monitor next
762 URLs checked: all returned HTTP 200 in the documented check.
293 PDF pages: all had noindex, in line with the defined policy.
28 redirects: 301 responses to equivalent destinations.
According to the technical report, the figures above were checked at the end of implementation. No sitemap URL had an unintended noindex, and the hashes of the 735 published content items remained identical.
These are implementation and verification results. The 11 validations were started, but they had not yet passed at the documented close. Search Console continued to show historical Core Web Vitals data, which depends on new visits and field data processing.
In the mobile letters test, the performance score was 99 both before and after. Lab CLS was already zero in both runs. Speed Index went from 2.925 s to 3.206 s in the final measurement. The comparison therefore does not demonstrate a reduction in historical CLS or an overall speed improvement. Final accessibility scores of 90 and 92 on the tested pages also retained warnings.
Follow-up should check each validation’s outcome, consistent exclusion of feeds and searches, sitemap consistency, and changes in field INP and CLS. Traffic comparisons need equivalent time windows and must account for queries, pages, and Brazilian school seasonality.
There are no subsequent measurements yet proving a recovery in clicks, sales, or revenue. The intervention established a technical basis for that follow-up. The historical analysis of iEducação’s organic traffic and sales covers a different period and must not be used as a result of these fixes.
Method and limitations: this article summarizes the intervention report provided by the responsible person, with AI assistance in organization and writing. Internal totals are attributed to that document; the full URL audit was not repeated here. The larger exclusion groups had a limit of 1,000 exportable examples. Lab and layout checks cover the pages and conditions described.
For a closer look at the difference between testing and real experience, also read High PageSpeed and a slow website: what to check before optimizing. Technical references include the documentation for page indexing, noindex, video structured data, Core Web Vitals, and CLS optimization.
Need to organize this kind of technical fix on your WordPress site? Let’s talk on WhatsApp.