Overview

ValidGraph automatically re-validates previously scanned URLs on a recurring schedule. This catches schema regressions caused by CMS updates, theme changes, plugin conflicts, or content edits — before search engines notice.

How It Works

1. After initial validation, URLs are queued for re-scanning
2. Re-scans run on the configured schedule
3. Results are compared to previous validations
4. New errors or score drops trigger alerts
5. Re-scan history is tracked in validation history

Tier Availability

| Tier | Frequency | URLs Re-scanned |
|——|———–|—————–|
| Free | — | — |
| Pro | Weekly | Last 10 URLs |
| Agency | Daily | All monitored URLs |
| Enterprise | Hourly | All monitored URLs |

Related Features

– URL Monitoring: Configure which URLs to monitor
– Email Alerts: Get notified of re-scan results
– Schema Change Detection: Detailed diff of what changed

Quick Start: Enable Automatic Re-scans

Step 1: Add URL to monitoring with a frequency

curl -X POST https://api.validgraph.io/wp-json/validgraph/v1/monitoring 
  -H "Authorization: Bearer YOUR_API_KEY" 
  -d '{
    "url": "https://example.com/article",
    "frequency": "daily"
  }'

Step 2: Re-scans start automatically on your configured schedule

Step 3: View rescan results in validation history for that URL

Step 4: Compare rescans — Dashboard shows previous score vs. latest score

Real-world scenario:
You deploy a theme update. Article pages re-scan automatically next day and show:
– Previous score: 85
– New score: 78 (regression detected!)
– 2 new validation errors found
– Email alert sent: “Schema regression detected”

Technical Details

Rescan Scheduling (Cron-based)

Pro tier:

Frequency: Weekly (every Monday 9:00 AM UTC)
URLs rescanned: Last 10 validated URLs only
Schedule: 0 9   1

Agency tier:

Frequency: Daily (every day 6:00 AM UTC)
URLs rescanned: All monitored URLs
Schedule: 0 6   *

Enterprise tier:

Frequency: Hourly (every hour at :00 minutes)
URLs rescanned: All monitored URLs
Schedule: 0    

Rescan Process Flow

1. Schedule trigger: Cron scheduler fires at configured time
2. Queue URLs: All eligible URLs are queued for validation
3. Fetch & validate: Each URL is fetched and validated (same as URL validation)
4. Compare results: New validation is compared to previous validation
5. Generate diff: Schema changes are detected and summarized
6. Trigger alerts: Alert rules are evaluated; matching rules send notifications
7. Store history: Results are saved to validation history with rescan marker

Rescan Response Example

Request (automatic, no manual input needed):
The system automatically rescans based on schedule.

Access rescan history:

GET /wp-json/validgraph/v1/monitoring/mon_abc123/history

Response:

{
  "success": true,
  "data": {
    "monitoring_id": "mon_abc123",
    "url": "https://example.com/article",
    "rescan_history": [
      {
        "validation_id": "val_rescan_002",
        "timestamp": "2024-03-21T06:00:00Z",
        "scan_type": "automatic_rescan",
        "score": 78,
        "errors": 2,
        "warnings": 3,
        "types": ["Article"],
        "compared_to": "val_rescan_001",
        "comparison": {
          "score_change": -7,
          "new_errors": 2,
          "resolved_warnings": 1,
          "regression": true
        }
      },
      {
        "validation_id": "val_rescan_001",
        "timestamp": "2024-03-14T06:00:00Z",
        "scan_type": "automatic_rescan",
        "score": 85,
        "errors": 0,
        "warnings": 2,
        "types": ["Article"]
      },
      {
        "validation_id": "val_initial_001",
        "timestamp": "2024-03-01T14:30:00Z",
        "scan_type": "manual_validation",
        "score": 85,
        "errors": 0,
        "warnings": 2,
        "types": ["Article"]
      }
    ]
  }
}

Tier-Specific Rescan Coverage

| Tier | Frequency | URLs Rescanned | Total Monthly Rescans |
|——|———–|—————–|———————-|
| Free | — | — | — |
| Pro | Weekly | Last 10 only | ~40 per month |
| Agency | Daily | All monitored (max 50) | ~1,500 per month |
| Enterprise | Hourly | All monitored (unlimited) | ~unlimited |

Rescan Result Comparison

When a rescan completes, it’s automatically compared to the previous validation:

{
  "rescan_comparison": {
    "current_validation": "val_rescan_002",
    "previous_validation": "val_rescan_001",
    "score_change": {
      "previous": 85,
      "current": 78,
      "change": -7,
      "percent_change": "-8.2%"
    },
    "error_change": {
      "previous": 0,
      "current": 2,
      "new": ["Malformed datePublished", "Invalid author format"],
      "resolved": []
    },
    "warning_change": {
      "previous": 2,
      "current": 3,
      "new": ["Missing description"],
      "resolved": []
    },
    "schema_type_changes": {
      "lost_types": [],
      "new_types": [],
      "unchanged": ["Article"]
    },
    "detected_regression": true,
    "alert_triggered": true,
    "alert_id": "alert_emergency_xyz"
  }
}

Rescan Failure Handling

If a rescan fails (URL unreachable, timeout, etc.):

{
  "validation_id": "val_rescan_failed_003",
  "timestamp": "2024-03-21T06:00:00Z",
  "status": "failed",
  "error": {
    "code": "CONNECTION_TIMEOUT",
    "message": "URL did not respond within 30 seconds",
    "url": "https://example.com/article"
  },
  "retry_info": {
    "automatic_retry": true,
    "retry_at": "2024-03-21T07:00:00Z"
  },
  "alert_triggered": true
}

Automatic retries are attempted once; alert fires if both attempts fail.

References

– Cron Expression Guide: https://crontab.guru/
– Cron Syntax Reference: https://en.wikipedia.org/wiki/Cron
– HTTP Request Timeouts: https://tools.ietf.org/html/rfc7231#section-6.6.1
– Monitoring Best Practices: https://tools.ietf.org/html/rfc7230
– Schema.org Change Detection: https://schema.org/