© 2021 in the footer: the cheapest freshness signal a v...

The Mega Analyzer's E-E-A-T tab opens with a row that reads Footer copyright year is current (© 2026) when things are fine and Footer copyright year is stale (© 2023, now 2026) when they are not. What it is really measuring is whether anyone has looked at the bottom of the page since the template was built, because the year in a copyright line is the one date almost every site prints on every page and almost nobody reads on their own site. A visitor deciding whether to call reads it. A crawler that never runs your JavaScript reads it. The fix is usually one line in a footer partial, and the row exists because that one line stays wrong for years.

What the check actually tests

The detector runs in the analyzer's extract stage against the HTML the server sent, parsed with DOMParser. Nothing executes, so what the check sees is the number sitting in the markup, not whatever a script would have written into it. It takes document.body.textContent, collapses whitespace, and scans for a marker followed by a year: the © symbol, the literal (c), or the word "copyright", case-insensitive, then optional whitespace, then an optional range prefix (four digits, a hyphen or a dash, more optional whitespace), then the four digits it keeps. It throws away any year of 1990 or earlier and any year more than one ahead of the current year, and if several survive it keeps the largest. The current year is new Date().getFullYear() on the machine running the analyzer.

If no year survives, copyrightYear is null, no row renders, and nothing is scored. If one does, the row fails when the year is more than one behind: in 2026, a © 2025 passes and a © 2024 fails. The fail detail reads: A copyright line years behind is the cheapest "is this business still open" signal a visitor or an AI engine reads. Print the year from the server or a one-line script. The row is worth two points in the E-E-A-T bucket, and those two points join the bucket's denominator only when the row renders, so a page with no notice at all is neither rewarded nor punished.

Four edge cases matter before you go looking for the line.

The marker has to come before the year. © 2026 Acme Plumbing matches; © Acme Plumbing 2026 does not, because the parser expects digits right after the symbol and finds a name. A footer in that order produces no row at all, neither green nor red, and the Copyright Office's own example notice (© 2017 John Doe) is in the order the parser expects. © decodes to © in the parsed document, so an entity counts, and ©2026 with no space counts. All rights reserved 2024 with no symbol and no word "copyright" does not. Neither does Copr. 2026, even though Circular 3 accepts that abbreviation as a marker; the detector only knows the three above.

Ranges only parse when they use a hyphen or a dash. © 2019-2026 reads as 2026. © 2019 to 2026 reads as 2019, because the word breaks the range prefix and the first four digits are the ones captured, so a range written out in words fails while the same range with a hyphen passes.

The largest year wins, and the scan covers the whole body. A page that quotes an old notice inside a license text or a press-release archive is fine as long as the footer is current. The reverse also holds: textContent includes the text of <script> and <style> elements, so a JSON-LD block placed in the body with "copyrightNotice": "© 2026 Acme" or an inline script holding a current year string turns the row green while the visible footer still says 2021. Green means "a current year exists somewhere in the body text", not "the footer is right".

A script that writes the year without a printed fallback produces no row. © <script>document.write(new Date().getFullYear())</script> contains no four digits in the served HTML, so the analyzer sees a marker followed by code and skips it. Whatever your browser shows you, the fetched page is what gets scored, and the same is true of any crawler that does not render JavaScript.

Why it matters

Start with the person. In the audits I have done for local businesses, the footer year is the thing a buyer brings up unprompted when asked whether a company looks like it is still operating. They do not check the sitemap. They scroll to the bottom, see a year from before the pandemic, and go back to the search results. The copyright line is on every page, it is the last thing visible before the page ends, and it is a number, so it gets read even when nothing else does. The analyzer's detail line calls it the cheapest signal for a reason: it costs nothing to read and nothing to fix.

Then Google. Its documentation on byline dates says "Google doesn't depend on a single date factor because all factors can be prone to issues", and among its best practices are "Make your dates and times consistent. Ensure that the date (and optional time and timezone) match between the equivalent user-visible and structured values" and "Minimize the presence of other dates on the page: If you've followed the best practices and find incorrect dates are being selected, consider removing some or all other dates that appear on the page." That page does not mention copyright lines or footers, and I am not going to claim Google reads a footer year as a publication date, because I cannot source it. What I can say is that a footer year is a date on every URL of the site, it is the one "other date" that appears on every page, and when it is stale it disagrees with every dateModified you emit. Google's advice is to make the visible dates and the structured dates match; a footer that says 2023 under an article whose schema says 2026 is a visible date that does not.

Then the retrievers. The site's own Retrieval Freshness Signal Audit checks for a current-year mention in the body text as one of six freshness proxies, and that check is observational, not something any AI engine documents. A correct footer is the one current-year mention every page on the site carries for free. A stale footer is the opposite: a wrong year on every page, read by any engine that fetches the HTML and does not run scripts.

Then the law, which cuts the other way and is why the fix needs a little care. The U.S. Copyright Office's Circular 3 lists the three elements of a notice as the symbol (or the word "copyright", or the abbreviation "copr."), "the year of first publication of the work", and the owner's name, and it says notice "is optional for works published on or after March 1, 1989". So a site launched in 2019 that prints © 2019 is stating a true fact about first publication, and the year in a notice was never meant to be a clock. The way to satisfy both readers is the range: the first year is first publication, the second is the latest year you published new material, so it moves whenever the site does. The circular also says that when notice is optional "copyright owners can use any form of notice they wish", so a range is not a stretch.

For the record, this site's base layout hardcodes © 2026. It passes today. It will go red in January 2028 unless someone edits the template, and nobody edits a template for a year that has not arrived yet. That is the whole failure mode: the year gets typed once, when the footer is built, and it is correct for a while.

How to fix it

Step 1: find where the year is printed. Search the theme or layout folder for ©, ©, (c) and copyright. On most sites it is a single footer partial. On a page builder or a hosted platform it is a footer widget setting, and the year was typed into a text field by whoever set the site up. If your search turns up two lines (a footer and a legal page, say), fix both, because the analyzer keeps the largest year and a human does not.

Step 2: print the year from the server or the build instead of typing it. On PHP, including a WordPress theme's footer.php or a child theme, the whole change is one expression:

<p>&copy; 2019-<?php echo date('Y'); ?> Example Plumbing. All rights reserved.</p>

On Eleventy, add a global data file so every layout can read year:

// src/_data/year.js
export default () => new Date().getFullYear();

Then output year in the footer with the template language's normal double-brace expression (which I cannot print inside this post because the post itself is rendered by that engine). Hugo has now.Year for the same job, Liquid has a date filter that takes "now", and every server-side language has a one-call equivalent. The point is that no human types the number.

Step 3: keep a range if you have one, and let the build move only the end year. Write it with a hyphen, which is what the analyzer parses, and keep the notice in the order the Copyright Office example uses: symbol, years, owner. Do not write the range in words.

Step 4: if the site is a static build, add a client-side fallback on top, not instead. A static build prints the year at build time, and a site that is not rebuilt between late December and whenever you next deploy shows last year's number to everyone who visits in January. The fallback fixes what the visitor sees; the printed number is what the analyzer and the non-rendering crawlers see; you want both right. In the before-and-after shape the Code-Diff Patch Generator uses for its own findings, the change is:

--- a/_includes/footer.html
+++ b/_includes/footer.html
@@ -1,1 +1,2 @@
-<p>&copy; 2021 Example Plumbing. All rights reserved.</p>
+<p>&copy; 2019-<span id="jw-year">2026</span> Example Plumbing. All rights reserved.</p>
+<script>document.getElementById('jw-year').textContent = new Date().getFullYear();</script>

Two rules for the script. It replaces a printed year; it never replaces a blank, because a blank is exactly the no-row case from the first section. And it is not the fix, it is insurance. If your build tool has a scheduled or hook-triggered rebuild, schedule one for the first week of January and the fallback will rarely fire.

The patch generator does not detect the footer year itself; it writes diffs for head-level findings like a missing canonical or an unsized LCP image. I mention it because you will be in the base layout anyway, and running it once against the same URL hands you the rest of the layout fixes in the same format, so one edit session closes several rows.

Step 5: verify in three places. Re-run the Mega Analyzer and open the E-E-A-T tab; the row should read Footer copyright year is current with this year in the parentheses. Run the Retrieval Freshness Signal Audit on a content page and confirm the "Current year (2026) mentioned in body" row is green, since the footer now supplies it on every page (that tool reads the first 30,000 characters of body text, so on a very long page the footer can sit past its window). Then load the page in a private window on January 2 (or fake the date on a test machine) and check the fallback flips the number without the build.

If you are rebuilding the footer's trust block at the same time, the E-E-A-T Workbench Generator emits an "Est. 2015" badge with a computed years-in-business count. That count is calculated when you click generate and pasted as a plain number, so it is a second hardcoded clock. Either print it from the same build variable as the copyright year or leave the count off and keep the founding year, which does not change.

When to leave it alone

Some sites are supposed to be frozen. An archived conference site, a discontinued product's documentation, a memorial page, a campaign that ended: the stale year is the truth, and moving it would say the site is maintained when it is not. Add a visible line near the top that says the site is archived and as of when, and accept the red row. Two points in one bucket is the right price for an honest date.

A site that prints only its first-publication year and genuinely has not published anything new since is also telling the truth, and Circular 3 backs the year it chose. The row still fails, and it should, because the finding is not the number. A business site that has added nothing in three years has a content problem that a footer edit will not fix, and the row is the cheapest place that problem shows.

A site with no notice at all is fine legally and invisible to this check. Notice has been optional for works published since March 1, 1989, and the analyzer renders nothing and scores nothing when it finds no year. Adding one costs a line and identifies the owner to anyone seeking permission, which the circular lists as a benefit, but do not add a notice to earn a green row.

Do not bump the year forward to be safe. The filter accepts one year ahead (enough to cover a server that has already crossed into New Year while the analyzer's machine has not) and drops anything further out, so a © 2030 makes the row disappear instead of passing. More to the point, the year in a notice claims a publication year, and a claim about a year that has not happened is a false statement in a legal notice, for nothing.

And if the footer is about to be replaced by a redesign, fix it in the new template rather than the old one. The row will keep failing for a week; it has been failing for three years.

Fact-check notes and sources

Source: https://developers.google.com/search/docs/appearance/publication-dates establishes the quotes above: "Google doesn't depend on a single date factor because all factors can be prone to issues", "Make your dates and times consistent", and "Minimize the presence of other dates on the page". As of 2026-09-21 the page does not mention copyright lines or footers.
Source: https://www.copyright.gov/circs/circ03.pdf (U.S. Copyright Office, Circular 3, Copyright Notice, revised 03/2021) establishes the three elements of a notice (the symbol ©, the word "copyright", or the abbreviation "copr."; "the year of first publication of the work"; the owner's name), the example © 2017 John Doe, that notice "is optional for works published on or after March 1, 1989", that when optional "copyright owners can use any form of notice they wish", and the listed benefits of notice.
Source: https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent establishes that textContent "gets the content of all elements, including <script> and <style> elements", which is why a current year inside a body script counts toward this check.
Source: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/getFullYear establishes that getFullYear() returns the year according to local time, which is the clock the analyzer compares against.
The detector, thresholds, and scoring weight described above were read from the Mega Analyzer's source on 2026-09-21: marker plus optional range plus four digits, years kept when greater than 1990 and at most one year ahead, largest year wins, stale when more than one year behind, two points in the E-E-A-T bucket.

© 2021 in the footer: the cheapest freshness signal a visitor or an AI engine reads