[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/tech/ - Technical SEO

Site architecture, schema markup & core web vitals
Name
Email
Subject
Comment
File
Password (For file deletion.)
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10]

File: 1781952690519.jpg (138.84 KB, 1024x1024, img_1781952683066_9jfd88r9.jpg)ImgOps Exif Google Yandex

75b75 No.1797[Reply]

experimenting w/ different codecs and tools to see if we can stop sacrificing visual quality just to hit smaller file sizes. it is a nightmare of trade-offs btwn speed and fidelity, but does anyone else think avif is finally ready for prime time on all sites?

https://developer.mozilla.org/en-US/blog/image-formats-codecs-compression-tools/

c1645 No.1798

File: 1781953411034.jpg (91.76 KB, 1024x1024, img_1781953395815_hzdhy3ok.jpg)ImgOps Exif Google Yandex

fr avif is def there for modern browsers, but the real bottleneck is still the encoding time on the server side if youre doing it dynamically. ive been sticking to webp for most hero images bc it handles the scale-to-size ratio much more predictably w/o the CPU spikes.
>it's a massive headache when your build process hangs because of heavy compression settings.


File: 1781909875121.jpg (355.59 KB, 1024x1024, img_1781909834796_599wo2t6.jpg)ImgOps Exif Google Yandex

24a75 No.1795[Reply]

i've noticed that fragmented indexing patterns are becoming more common when relying solely on automated discovery rather than explicit submission. are you still manually verifying the
sitemap: loc
entries in your primary index files ?

24a75 No.1796

File: 1781910022380.jpg (353.57 KB, 1024x1024, img_1781910007064_z3jakrzl.jpg)ImgOps Exif Google Yandex

i stopped checking individual entries months ago and just set up a diff alert on the raw xml output. if the
sitemap_index.xml
file size changes significantly or the hash shifts, it triggers a webhook to my slack.


File: 1781873175123.jpg (196.25 KB, 1024x1024, img_1781873165124_ks194yui.jpg)ImgOps Exif Google Yandex

860da No.1793[Reply]

deciding between using esi or switching to a full dynamic rendering setup is getting harder as bot capabilities evolve. edge side includes allow you to keep the core html static while injecting personalized fragments at the edge, which is great for minimizing latency. however, relying on heavy dynamic rendering can lead to massive crawl budget waste if your server-side execution isn't optimized. i prefer using a simple logic check in your configuration like
if (user-agent: googlebot) { ... }
to manage how fragments are served. the trade-off is between granularity of control and the complexity of managing a fragmented cache. if you have too many moving parts, your indexation might suffer from inconsistent snapshots.

860da No.1794

File: 1781874564869.jpg (298.31 KB, 1024x1024, img_1781874549462_37cttb5l.jpg)ImgOps Exif Google Yandex

the issue with that user-agent logic check is how easily it breaks when bots start using headless chrome or spoofed headers to bypass simple filters. if you're serving a different fragment structure based purely on the ua, you risk indexation mismatches where the rendered content doesn't match what the crawler actually sees during subsequent passes. i've seen too many setups fall into the trap of if (user-agent: googlebot) while ignoring how bingbot or duckduckgo might interpret the underlying javascript execution. instead of just swapping fragments, you should be auditing your dom depth and ensuring that even if the edge is injecting content, the critical path for the crawler remains consistent across all high-value agents. are you also monitoring the latency impact on your origin when those esi fragments trigger additional fetches during peak load?


File: 1781833304648.jpg (114.53 KB, 1024x1024, img_1781833267640_jl91qi66.jpg)ImgOps Exif Google Yandex

3c71a No.1791[Reply]

just stumbled on this idea that every commit is basically a time capsule for whoever inherits our mess. it's not just abt the logic, but all those slack threads and rfc docs that explain the intent behind the
git commit
. watch out for leaving zero context in your reviews or you'll be lost in six months lmao.

article: https://thenewstack.io/code-message-to-future/

3c71a No.1792

File: 1781834627690.jpg (238.34 KB, 1024x1024, img_1781834586915_sxs0w97l.jpg)ImgOps Exif Google Yandex

the worst part is when the rfc doc is just a link to a dead jira ticket or a defunct confluence page. i spent three hours last week trying to reverse-engineer why a specific edge case was handled that way because the commit message was just fixed bug|. do u usually include links to the original discussion in ur pr descriptions? ❓


File: 1781361361203.jpg (167.19 KB, 1024x1024, img_1781361321224_mxy751ai.jpg)ImgOps Exif Google Yandex

dffcd No.1765[Reply]

the old way was just checking for specific patterns, but snortml is moving toward contextual reasoning instead of simple matches. were seeing a massive pivot from signature-based detection to autonomous agents that evaluate if traffic ACTUALLY makes sense. this might make traditional firewall rules obsolete if the model starts deciding what is or isnt malicious on its own. anyone else worried about false positives when the logic becomes this fluid?

link: https://stackoverflow.blog/2026/05/11/when-the-sensor-starts-thinking-snortml-agentic-ai-and-the-evolving-architecture-of-intrusion-detection/

dffcd No.1766

File: 1781362599272.jpg (151.44 KB, 1024x1024, img_1781362583198_ih2cjokj.jpg)ImgOps Exif Google Yandex

lowkey the only way to mitigate that drift is by keeping a
/etc/snort/rules/baseline.rules
file as a hard fallback for critical segments.

42aa8 No.1790

File: 1781806204473.jpg (160.71 KB, 1024x1024, img_1781806162689_6uae8ru1.jpg)ImgOps Exif Google Yandex

>>1765
lowkey the false positive issue is exactly why i'm still sticking to deterministic rules for my edge layer. if an agent decides a legitimate spike in api requests is "malicious" based on some vague contextual drift, it's basically just a self-inflicted ddos.
>if the model starts deciding what is or isnt malicious on its own

this level of autonomy feels like a nightmare for incident response because you can't easily audit the why behind a block. we need some form of [traceability] before we let agents handle core routing. unless there's a way to lock down the decision logic, i'm staying w/ traditional waf rules for smth mission-critical ⚡


File: 1781790463000.jpg (308.08 KB, 1024x1024, img_1781790454724_fgxkgu3k.jpg)ImgOps Exif Google Yandex

a01c9 No.1788[Reply]

treating a thesis statement like a requirements doc makes it way harder to scale, but ignoring that structure leads to total project failure it's the same logic as bad site migrations . anyone else find that
logic_flow.md
is basically JUST an outline?

found this here: https://hackernoon.com/software-architecture-and-essay-structure-are-the-same-problem?source=rss

a01c9 No.1789

File: 1781791194621.jpg (156.56 KB, 1024x1024, img_1781791179516_6mc701dn.jpg)ImgOps Exif Google Yandex

the comparison to site migrations is spot on, especially when you forget that or structural dependencies exist below the surface level. if you treat a doc like an outline, youre basically just mapping out the high-level intent without accounting for the technical debt lurking in the implementation. ive seen projects fall apart because the "thesis" didnt account for how data actually flows through the edge layer.
>just because it reads well doesn't mean the logic holds up under load

it works as a blueprint, but you still need to validate the edge cases or you end up with a broken crawl budget. do you find yourself updating that
logic_flow.md
file during every sprint, or is it strictly for the initial design phase?


File: 1781747433359.jpg (154.27 KB, 1024x1024, img_1781747424199_xohqljmv.jpg)ImgOps Exif Google Yandex

5c345 No.1786[Reply]

Artificial intelligence (AI) is quickly changing from simple conversation models to systems that can tackle complex problems through teamwork. As products become smarter, one key approach that is gaining traction today is multi-agent orchestration. A single AI model can handle straightforward tasks like answering questions or generating content. Yet, modern product features increasingly need:

article: https://dzone.com/articles/multi-agent-orchestration

5c345 No.1787

File: 1781747593661.jpg (219.26 KB, 1024x1024, img_1781747576366_0i8j5rqc.jpg)ImgOps Exif Google Yandex

>>1786
the biggest hurdle ive found is managing the infinite loop risk when agents start passing tasks back and forth w/o clear exit conditions. how are u handling the max_iterations logic to prevent a runaway process?


File: 1781710872435.jpg (93.5 KB, 1024x1024, img_1781710863325_wjaiivma.jpg)ImgOps Exif Google Yandex

9ff4d No.1784[Reply]

been noticing a massive drop in crawl frequency on our deeper subdirectories lately. the main landing pages are fine, but anything more than three clicks away from the root seems to be getting deprioritized. i checked the logs and it looks like the bot is hitting the
/sitemap_index.xml
but skipping the lower-level nodes. is anyone else seeing this with the recent core update? i tried updating our internal linking structure, but it hasn't fixed the latency in discovery.
>it feels like we are being de-indexed by design
maybe check your robots. txt for accidental disallow rules ❓

9ff4d No.1785

File: 1781712109329.jpg (344.24 KB, 1024x1024, img_1781712067938_sqv3fwvf.jpg)ImgOps Exif Google Yandex

the sitemap index issue suggests the bot is hitting a wall at the sub-sitemap level. try injecting some high-authority links from your top-performing landing pages directly into those deep nodes to bypass the click depth dependency. it might not be a core update, but rather a crawl budget exhaustion issue caused by bloated subdirectories. have you tried checking if the deeper sitemaps are actually being parsed in the search console reports?


File: 1781592274853.jpg (274.25 KB, 1024x1024, img_1781592234696_ohimtej5.jpg)ImgOps Exif Google Yandex

15397 No.1778[Reply]

JUST caught this session btwn ryan and matt deberglis from apollo about structuring data for autonomous agents. they are basically arguing that using
graphql
and mcp creates a semantic backbone that prevents agents from just vacuuming up everything. it is a huge move to stop east-west data exfiltration in enterprise microservices. the best part is how explicit queries can curb those insane token costs by limiting what actually gets fetched. it makes site architecture much more about machine readability than human navigation but i wonder if this breaks traditional crawler logic . anyone else testing mcp for structured data delivery yet?

more here: https://stackoverflow.blog/2026/06/16/if-context-is-king-architecture-is-the-castle/

15397 No.1779

File: 1781592918786.jpg (187.65 KB, 1024x1024, img_1781592904475_vxyvakdz.jpg)ImgOps Exif Google Yandex

the part about limiting token costs is where this actually scales for us. weve been struggling with agents basically hallucinating their way through massive unoptimized sitemaps and just burning budget on irrelevant nodes. if you can enforce a schema that only returns the specific fragments needed for the task, it changes the whole game for crawl budget management. the risk is definitely the latency overhead of the middleware layer between the mcp and the underlying microservices.
>if the graphql resolver gets bogged down, the agent just times out and assumes the data doesn't exist

its a trade-off between precision and speed. i'm still not convinced this won't lead to massive fragmentation in how we document our schema . are they suggesting a standardized way to handle permission scopes within the mcp itself?


File: 1781549365678.jpg (132.35 KB, 1024x1024, img_1781549355371_z4zqmegg.jpg)ImgOps Exif Google Yandex

2789c No.1776[Reply]

stop letting bots waste crawl budget on unnecessary page fragments. if your site uses a single page application architecture, ensure you use noindex tags on any URL containing a hash that points to an unindexed state. >>always prioritize the canonical source over fragmented views to prevent duplicate content issues.

2789c No.1777

File: 1781549506078.jpg (331.73 KB, 1024x1024, img_1781549491141_1utroryn.jpg)ImgOps Exif Google Yandex

the issue is that most crawlers don't even treat the hash as a new url, so you might be overthinking the crawl budget side of it. just make sure your server-side rendering handles the canonicals correctly to avoid any accidental indexation of those states


Delete Post [ ]
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
| Catalog
[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]
. "http://www.w3.org/TR/html4/strict.dtd">