At HiSarkariResult we publish government job notifications, results and syllabus pages. Job pages expire, pay scales need to be accurate, and sections grow at very different rates. We learned that SEO output needs the same discipline as any other output: a clear owner in the codebase, and tests.

This post covers three patterns you can drop into a Laravel app:

1. A small builder class for JobPosting JSON-LD instead of inline Blade arrays.

2. Feature tests that render a page, extract the JSON-LD and assert on it.

3. Paginated sitemap routes with HTTP caching (Last-Modified / 304), as an alternative to pre-generating files.

All the code is generic example code. Adapt names to your own models.

1. A dedicated builder for JobPosting

Google's JobPosting documentation lists title, description, datePosted, hiringOrganization and jobLocation as required properties. It recommends validThrough, employmentType, baseSalary and identifier. When those rules live inside a Blade template they're hard to test, so we give them their own class:

namespace App\Seo;

use App\Models\Post;

final class JobPostingSchema
{
    public function __construct(private Post $post) {}

    public static function for(Post $post): self
    {
        return new self($post);
    }

    public function isEligible(): bool
    {
        return $this->post->type === 'job'
            && $this->post->published_at !== null
            && ($this->post->valid_through === null || $this->post->valid_through->isFuture());
    }

    public function toArray(): ?array
    {
        if (! $this->isEligible()) {
            return null;
        }

        $p = $this->post;

        return array_filter([
            '@context' => 'https://schema.org',
            '@type' => 'JobPosting',
            'title' => $p->post_name ?? $p->title,
            'description' => $p->body_html,
            'identifier' => $p->advertisement_no ? [
                '@type' => 'PropertyValue',
                'name' => $p->organisation_name,
                'value' => $p->advertisement_no,
            ] : null,
            'datePosted' => $p->published_at->toDateString(),
            'validThrough' => $p->valid_through?->copy()->endOfDay()->toAtomString(),
            'employmentType' => 'FULL_TIME',
            'hiringOrganization' => array_filter([
                '@type' => 'Organization',
                'name' => $p->organisation_name,
                'sameAs' => $p->official_url,
            ]),
            'jobLocation' => [
                '@type' => 'Place',
                'address' => array_filter([
                    '@type' => 'PostalAddress',
                    'addressRegion' => $p->state,
                    'addressCountry' => 'IN',
                ]),
            ],
            'baseSalary' => $this->salary(),
            'directApply' => false,
        ], fn ($v) => $v !== null && $v !== []);
    }

    private function salary(): ?array
    {
        if (! $this->post->pay_min) {
            return null;
        }

        return [
            '@type' => 'MonetaryAmount',
            'currency' => 'INR',
            'value' => array_filter([
                '@type' => 'QuantitativeValue',
                'minValue' => $this->post->pay_min,
                'maxValue' => $this->post->pay_max,
                'unitText' => 'MONTH',
            ]),
        ];
    }

    public function toScriptTag(): string
    {
        $data = $this->toArray();

        if ($data === null) {
            return '';
        }

        $json = json_encode(
            $data,
            JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE | JSON_HEX_TAG | JSON_THROW_ON_ERROR
        );

        return '<script type="application/ld+json">' . $json . '</script>';
    }
}

A few details that matter:

• Salary ranges from the pay matrix. For Indian central government posts, the pay level in the notification maps to a published range. For example, the SSC CGL 2026 notice lists Pay Level-7 as ₹44,900 to ₹1,42,400. Store pay_min and pay_max from the notice rather than typing numbers into templates.

• JSON_HEX_TAG escapes < and >, so a description containing </script> can't break out of the tag.

• JSON_THROW_ON_ERROR turns invalid UTF-8 from a copy-pasted PDF into a loud exception instead of a silent false.

In Blade the template stays tiny:

{!! \App\Seo\JobPostingSchema::for($post)->toScriptTag() !!}

2. Unit-test the rules, feature-test the output

Unit tests guard the business rules: which posts are eligible and which fields must exist.

use App\Models\Post;
use App\Seo\JobPostingSchema;

it('includes every property Google marks as required', function () {
    $post = Post::factory()->job()->create([
        'valid_through' => now()->addDays(10),
    ]);

    $schema = JobPostingSchema::for($post)->toArray();

    expect($schema)->toHaveKeys([
        'title', 'description', 'datePosted', 'hiringOrganization', 'jobLocation',
    ]);
});

it('drops the markup once the last date has passed', function () {
    $post = Post::factory()->job()->create([
        'valid_through' => now()->subDay(),
    ]);

    expect(JobPostingSchema::for($post)->toArray())->toBeNull();
});

it('never adds JobPosting to non-job content', function () {
    $post = Post::factory()->create(['type' => 'result']);

    expect(JobPostingSchema::for($post)->toArray())->toBeNull();
});

Feature tests catch the things unit tests miss: the partial not being included, a layout change swallowing the tag, or a second, conflicting JSON-LD block appearing. A small helper that parses the rendered HTML keeps the tests readable:

function jsonLdBlocks(string $html): array
{
    preg_match_all(
        '#<script type="application/ld\+json">(.*?)</script>#s',
        $html,
        $matches
    );

    return array_map(
        fn (string $json) => json_decode($json, true, flags: JSON_THROW_ON_ERROR),
        $matches[1]
    );
}

it('renders exactly one JobPosting block on an open job page', function () {
    $post = Post::factory()->job()->create(['valid_through' => now()->addWeek()]);

    $html = $this->get(route('posts.job', ['slug' => $post->slug]))
        ->assertOk()
        ->getContent();

    $types = array_column(jsonLdBlocks($html), '@type');

    expect(array_count_values($types)['JobPosting'] ?? 0)->toBe(1);
});

These are Pest tests. The same assertions work in PHPUnit with assertArrayHasKey and assertNull. Automated tests don't replace Google's Rich Results Test, but they stop regressions from reaching production in the first place.

3. Paginated sitemap routes with HTTP caching

Pre-generating sitemap files with a scheduled command works well. The alternative below suits sites that deploy to several servers or don't want a writable public/ directory: serve sitemaps from routes, paginate them, and let HTTP caching do the heavy lifting.

// routes/web.php
Route::get('/sitemap.xml', [SitemapController::class, 'index']);
Route::get('/sitemaps/{section}-{page}.xml', [SitemapController::class, 'section'])
    ->whereIn('section', ['jobs', 'results', 'syllabus', 'admission'])
    ->whereNumber('page');

namespace App\Http\Controllers;

use App\Models\Post;
use Illuminate\Http\Request;

class SitemapController extends Controller
{
    private const PER_PAGE = 5000; // well under the protocol's 50,000-URL limit

    private const TYPES = [
        'jobs' => 'job',
        'results' => 'result',
        'syllabus' => 'syllabus',
        'admission' => 'admission',
    ];

    public function index(Request $request)
    {
        $files = [];

        foreach (self::TYPES as $section => $type) {
            $query = Post::where('type', $type)->whereNotNull('published_at');
            $pages = (int) ceil($query->count() / self::PER_PAGE);

            for ($page = 1; $page <= $pages; $page++) {
                $files[] = url("/sitemaps/{$section}-{$page}.xml");
            }
        }

        return response()
            ->view('sitemaps.index', ['files' => $files])
            ->header('Content-Type', 'application/xml');
    }

    public function section(Request $request, string $section, int $page)
    {
        $query = Post::where('type', self::TYPES[$section])->whereNotNull('published_at');

        $lastModified = (clone $query)->max('updated_at');
        abort_if($lastModified === null, 404);

        $response = response()->noContent(200);
        $response->setLastModified(new \DateTime($lastModified));

        if ($response->isNotModified($request)) {
            return $response; // Symfony turns this into a 304 with no body
        }

        $posts = $query->orderBy('id')
            ->forPage($page, self::PER_PAGE)
            ->get(['id', 'slug', 'type', 'updated_at']);

        abort_if($posts->isEmpty(), 404);

        return response()
            ->view('sitemaps.urlset', ['posts' => $posts])
            ->header('Content-Type', 'application/xml')
            ->setLastModified(new \DateTime($lastModified));
    }
}

The URL set view (use {!! !!} for the XML declaration so Blade doesn't choke on <?):

{!! '<?xml version="1.0" encoding="UTF-8"?>' !!}
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
@foreach ($posts as $post)
    <url>
        <loc>{{ route('posts.' . $post->type, ['slug' => $post->slug]) }}</loc>
        <lastmod>{{ $post->updated_at->toAtomString() }}</lastmod>
    </url>
@endforeach
</urlset>

Why the Last-Modified dance? Crawlers that send If-Modified-Since get an empty 304 when nothing in that section has changed, so an unchanged sitemap costs one MAX(updated_at) query instead of thousands of rows. Put a CDN or reverse proxy in front and the savings compound.

Two gotchas:

• Ordering must be stable. Paginate by id, not by updated_at. Otherwise every edit shuffles URLs between pages, and crawlers see churn that isn't real.

• Don't rely on sitemap "pings". Google deprecated the sitemap ping endpoint in 2023. Reference the index in robots.txt, submit it once in Search Console, and keep <lastmod> honest. Only bump updated_at when the content actually changes, not on every view count increment.

Test the sitemap too

A quick feature test keeps the XML valid and the counts right:

it('lists published results in the first results sitemap', function () {
    $posts = Post::factory()->count(3)->create([
        'type' => 'result',
        'published_at' => now(),
    ]);

    $xml = simplexml_load_string(
        $this->get('/sitemaps/results-1.xml')->assertOk()->getContent()
    );

    expect(count($xml->url))->toBe(3);
});

Wrapping up

None of this is exotic. The shift is in mindset: JSON-LD and sitemaps are output your application produces, so give them a home in app/, cover them with tests, and let HTTP semantics handle caching. Search engines are just another client, and they deserve the same correctness as your users.